whose cc recognises byte moves - Page 2

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: whose cc recognises byte moves

Quoted text here. Click to load it

How about:
    long int x;

    x = 1 << 17;                // Undefined on 16-bit int architecture -
probably 0
    x = 131072;                // Works fine - the constant is a long int





Re: whose cc recognises byte moves
Quoted text here. Click to load it
... snip ...
Quoted text here. Click to load it

The // is also undefined unless you have a C99 compiler.  At any
rate, the following is *always* defined, and is also a compile
time constant:

      x = 1L << 17;   /* What the L modifier is for */

--
Chuck F ( snipped-for-privacy@yahoo.com) ( snipped-for-privacy@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
We've slightly trimmed the long signature. Click to see the full one.
Re: whose cc recognises byte moves

Quoted text here. Click to load it

If you ask this question in comp.lang.c. I am sure they will give you
quite a number of examples.
I once asked why there was no rotate instruction in C, because all
CPUs I have worked with had rotate. They came back with some very odd
computer architectures for which C is used where rotate is impossible
to impliment.


Regards
  Anton Erasmus


Re: whose cc recognises byte moves
Quoted text here. Click to load it
... snip ...
Quoted text here. Click to load it

Try strlcpy and strlcat, as defined by BSD.  You can find an
implementation at:

  <http://cbfalconer.home.att.net/download/strlcpy.zip

which also has references to the original analysis and
reasonings.  These routines are designed to avoid silly errors on
the part of the user.

--
Chuck F ( snipped-for-privacy@yahoo.com) ( snipped-for-privacy@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
We've slightly trimmed the long signature. Click to see the full one.
Re: whose cc recognises byte moves
Quoted text here. Click to load it

Yes we corrected that tupo once already.  Sorry it exists.
Specifically I omitted the & 0xFF.

Quoted text here. Click to load it

A comparably popular competing rule of thumb is used signed quantities
always e.g. in C always say signed char.

Pat LaVarre

Re: whose cc recognises byte moves
Quoted text here. Click to load it

Fully agreed.


I strongly doubt that this rule is anywhere near popular.  The average
C programmer isn't that silly --- or so I keep hoping.  

To be perfectly clear about this: this rule-of-thumb is too stupid to
live.  For starters, there's no way you can correctly use the standard
<ctype.h> functions/macros in a portable manner while sticking to that
rule.

Signed chars have exactly one kind of non-silly usage: as very small
integers.  Using them to represent characters in actual text gives you
just a desaster waiting to happen.

--
Hans-Bernhard Broeker ( snipped-for-privacy@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Re: whose cc recognises byte moves
Quoted text here. Click to load it

I see this in code fragments written to run as C or as Java.  I
thought these might be coming out of a tradition of signed-char
32-bit-int Unix, but personally I'm decidely vague on how the world
has split between signed and unsigned bytes express in C as type char.

Quoted text here. Click to load it

Sorry I was unclear.  Java uses 16 unsigned bits, perhaps unsigned
short in C, to mean UTF-16 char.  I meant to be talking about signed
bytes.  Java has only signed bytes, no unsigned bytes.

Pat LaVarre

Re: whose cc recognises byte moves
Quoted text here. Click to load it


And in that case, it's entirely the *Java* side of that which would be
governing it.  IIRC, Java has no unsigned types at all.

OTOH, trying to write code that works in more than one different
language is even sillier than that rule of thumb.  It can be a nice
game (the record achievement being more than 20 languages that can all
execute a given file, IIRC), but it's quite certainly useless in any
productive environment.  The idea of there being a programming
language "C/C++" you can write program in has wreaked enough havoc to
people's education already --- no point in making that even worse.

--
Hans-Bernhard Broeker ( snipped-for-privacy@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Re: whose cc recognises byte moves
Quoted text here. Click to load it

Whether Java does or does not accurately represent a signed-char
32-bit-int Unix C design tradition passed person-to-person, I do not
know.

Quoted text here. Click to load it

That is, in Java as specified, signedness is always implicit, never
explicit or otherwise indeterminate.  Instead, all of byte, short,
int, long are always signed and char is always unsigned.  That is, in
Java (96?) we see a different way of spelling the C99 <stdint.h> ideas
of int8_t, int16_t, int32_t, int64_t and uint16_t.

In particular, Java char by definition works like the unsigned
two's-complement sixteen bits that often we can get via C unsigned
short (and perhaps wchar?) e.g.

$ cat hi.java
class hi {
 
        public static void main(String[] args)
        {
                int i = -1;
                char ch = (char) i;
                int j = (int) ch;
                System.err.println(j);
                System.err.println("x" + Integer.toHexString(j));
        }
 
}
$ javac hi.java
$ java hi
65535
xffff
$
$ # Pat LaVarre

Re: whose cc recognises byte moves

Quoted text here. Click to load it


... and of completely lacking all the others.  And Java's (16-bit)
"char" is not really a uint16_t --- unless memory betrays me, it
completely lacks arithmetic operators working on it.  If you can't
multiply it by 17, it doesn't qualify as an integer data type.

Quoted text here. Click to load it

Care to enlighten what could possibly be "two's-complement" about an
*unsigned* integer type?

--
Hans-Bernhard Broeker ( snipped-for-privacy@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Re: whose cc recognises byte moves
Quoted text here. Click to load it

Java compiles { char ch = 13; ch *= 17; ... } without error.  Lossless
conversion from and lossy conversion to int occurs implicitly, much as
in C.

Perhaps you're reminding us that an expression like ((ch < 31) * 17)
is a compile-time error in Java.  Promotion to int from boolean in
Java is not implicit: in Java that intent has to appear explicitly
e.g. (((ch < 31) ? 1 : 0) * 17).  In this sense, the Java boolean type
is not a one-bit unsigned integral type.

Quoted text here. Click to load it

"All the nonnegative encodings, of course", is my first thought.  I
wonder if I have misunderstood the question.  In review, I think the
JLS says what I meant better than I did e.g. in JLS2 4.2:

"The integral types are byte, short, int, and long, whose values are
8-bit, 16-bit, 32-bit and 64-bit signed two's-complement integers,
respectively, and char, whose values are 16-bit unsigned integers
representing Unicode characters."

That text precisely avoids restating that "everyone knows" the values
of "a 16-bit unsigned integer" are x0000 thru xFFFF inclusive.

Quoted text here. Click to load it

Aye, apparently on purpose.

I see Google doesn't immediately remind me who first said, in design,
sometimes less is more.

Pat LaVarre

Site Timeline