Re: Patch b4_uint_type and b4_sint_type range problem

[Akim Demaille]

| This showed up when I recently ran the testsuite on a Sparc 
| Solaris installation.
| 
| m4 evaluates integer expressions as 32-bit signed quantities.  As a
| result, the b4_sint_type and b4_uint_type definitions don't work for
| arguments larger than 32767 or 65535, respectively.  More precisely,
| with b4_sint_type, NO argument will cause the error message, whereas
| with b4_uint_type, ANY argument larger than 65535 will cause a fatal
| m4 error (because 4294967295 == -1 mod 2**32).  

Arg, I forgot sizes could be different :(

| The simplest solution (albeit kludgy) is simply not to test for the 
| problematic cases, as indicated in the patch below. It is unlikely
| that one would ever trip over these particular errors, after all.

Agreed.

| Technically, I think there is another problem here, although I don't
| have an up-to-date C standard to check---the type 'int' is not really 
| guaranteed to have 32 bits; 'long int' is.  

The GNU project disregards this case.

        Portability between CPUs
        ========================
        
           Even GNU systems will differ because of differences among CPU
        types--for example, difference in byte ordering and alignment
        requirements.  It is absolutely essential to handle these differences.
        However, don't make any effort to cater to the possibility that an
        `int' will be less than 32 bits.  We don't support 16-bit machines in
        GNU.


| P.S. I am posting this for approval rather than just doing it since
| (1) it is not specific to the stuff I'm working on, and 

Nope, but you did find an issue, so :)

| (2) as a newbie to this group, I prefer caution.

Well, welcome, and enjoy the tour :)