> > Recent changes in pg_crc.c (64 bit CRC) introduced non
> portable constants of the form:
>
> > -c -o pg_crc.o pg_crc.c
> > 287 | 0x0000000000000000, 0x42F0E1EBA9EA3693,
> > ............................a..................
> > a - 1506-207 (W) Integer constant 0x42F0E1EBA9EA3693 out of range.
>
> Please observe that this is a warning, not an error. Your proposed
> fix is considerably worse than the disease, because it will break on
> compilers that do not recognize "LL" constants, to say nothing of
> machines where L is correct and LL is some yet wider datatype.
>
> I'm aware that some compilers will produce warnings about these
> constants, but there should not be any that fail completely, since
> (a) we won't be compiling this code unless we've proven that the
> compiler supports a 64-bit-int datatype, and
Unfortunately configure does not check the use of 64 bit integer
constants. A little check on AIX shows, that it indeed DOES NOT work !!!!!
$ ./a.out
hex: 0x012345670ABCDEF0LL==12345670abcdef0, 0x012345670ABCDEF0==abcdef02ff22ff8
> (b) the C standard
> forbids a compiler from requiring width suffixes (cf. 6.4.4.1 in C99).
Maybe that standard is somewhat too recent to rely upon 100%.
> I don't think it's a good tradeoff to risk breaking some platforms in
> order to suppress warnings from overly anal-retentive compilers.
I really do expect other compilers to break on this too. Thus I think
a workaround is needed. As it stands the code does not compute
a valid CRC64 on all platforms.
Do you want me to supply an AIX specific patch with #if defined (_AIX) ?
Andreas