inttypes.h bug leads to inconsistent warnings cross platform

[Eric Blake]

On 09/10/2014 03:13 PM, Jeff Johnston wrote:
> I was thinking of having something like:
> 
> <logic in newlib that figures out what uintptr_t is>
> 
> <PRIuPTR logic from newlib>
> 
> int printf(char *x, ...);
> 
> int main()
> {
>     uintptr_t p = 0;
> 
>     return printf("%" PRIuPTR "\n", p);
> }
> 
> then compile this with -Wall -Werror in the compilation test so it either
> fails or succeeds.  You then know that the PRIxPTR code needs tweaking.

That's fragile (depends on -Werror working), whereas you can do type
detection on ALL compliant C compilers via function pointer assignment
or function redeclaration.  Lightly tested, but observe how I can
quickly probe that uintptr_t is equal to unsigned long on my x86_64
GNU/Linux box, with no need for warning detection:

$ cat foo.c
#include <inttypes.h>
extern int foo(uintptr_t);
extern int foo(PROBE);
int main() { return 0; }
$ gcc -o foo foo.c -D PROBE='unsigned long'
$ gcc -o foo foo.c -D PROBE='unsigned long long'
foo.c:3:12: error: conflicting types for ‘foo’
 extern int foo(PROBE);
            ^
foo.c:2:12: note: previous declaration of ‘foo’ was here
 extern int foo(uintptr_t);
            ^
$

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 539 bytes
Desc: OpenPGP digital signature
URL: <http://sourceware.org/pipermail/newlib/attachments/20140911/8c13eef9/attachment.sig>