[Zlib-devel] #elif is not portable on pre-ANSI compilers

[Cosmin Truta]

On Thu, 17 Apr 2003, Greg Roelofs wrote:

> > I wish to add that even the use of 0xff00 should be accompanied by 'U'
> > (0xff00U), for the sake of 16-bit platforms. Even if the compiled code
> > is still correct, 0xff00 alone is a negative value that might cause
> > unnecessary warnings; after all, we are dealing with unsigned values.
>
> 'U' is an ANSIism.  I think it's widely supported on non-ANSI compilers,
> but I'd bet there are some that don't grok it.

If you grep [0-9][Uu] in the zlib sources, you will find that 'U' is
actually used quite thoroughly (including 0UL, 1UL). Did anyone ever
receive complaints about not being able to compile zlib, or anything
else, due to this suffix?

> If it ain't broke...

My 16-bit compiler complains about 0xff00 and about 429...295. Besides,
I was proposing to replace 429...295 with the safer and more readable
0xffffffffUL (after all, hex values are consistently used throughout the
crc32 code), but I admit "it ain't broke", and I don't care that much
about 16-bit platforms.

(For me, at least, it was easy to remember 32768, 65536, but I never
managed to remember 2^31, 2^32 in decimal)

Cosmin