whose cc recognises byte moves

Again, my point is that it isn't signed vs. unsigned that's the major concern here. Shifting of /any/ type is hazardous...

[snip]

I recall making a remark that a char is a char unless it's an int...

Argh!

Could you please provide some examples of computer architectures and compilers, in which shifting of _unsigned_ quantities would produce "unexpected" results.

The only example I can think of are the decimal (BCD) computers, but I have not seen those since the punched card era and I very much doubt that any of these would have a C-compiler (COBOL more likely).

However, shifting signed quantities is much more risky situation, with

2's complement, 1's complement and sign/magnitude representation.

Paul

int x;

x = 1

If int 16 bits, then the direct assignment would not work any better, since result can not be used anyway. The problem is that the int data type itself is not portable. Thus it is not much sense to blame the shift optation for portability problems.

Paul

... snip ...

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

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 (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
     USE worldnet address!

How about: long int x;

x = 1

... 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.

Care to enlighten what could possibly be "two's-complement" about an

*unsigned* integer type?

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

... snip ...

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

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

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.

"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.

Aye, apparently on purpose.

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

Pat LaVarre