Re: Proto-patch for "%I64" on Microsoft

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Fri, 26 Nov 2004, Mark Mitchell wrote:

> What do you think of this patch?  
> 
> I know it's missing a ChangeLog and documentation.  
> 
> I've also not tried to be thorough about handling all of Microsoft's
> print specifiers, nor worried at all about their scanf specifiers.
> I'm just trying to fix the bootstrap on Windows; if the port
> maintainers want to go beyond that, that's their concern.
> 
> Assuming I added the appropriate documentation, would this patch be OK
> with you?

For fixing bootstrap on Windows for now I'd prefer something more minimal, 
e.g. -Wno-format or -fno-builtin-printf on bootstrap.  (And longer term 
avoiding the vagiaries of the system printf in GCC altogether, though this 
only addresses bootstrap issues and not wider questions.)

In general the problem is that the format warnings - especially for local 
functions with printf format attribute, which might not go through the 
system printf - could be interpreted either of two ways: warn about uses 
in connection with some fixed set of format specifiers, or warn about uses 
not supported by the system's format functions.  Historically it has been 
the former; the set hasn't quite corresponded with glibc (e.g. GCC 
interprets scanf %as in the C99 way in C99 mode, although glibc interprets 
it in a nonconforming way), and clearly in standards conformance modes it 
is meant to be a fixed set.  The former is a lot more readily testable 
than the latter.  The latter is also useful but we haven't attempted to do 
it.

There hasn't been any general consistent policy about whether in a 
particular area we should provide the same GNU C on all systems or vary 
with the particular system; we follow the system for signedness of char, 
but not for signedness of bit-fields, for example.  I suspect we want two 
different options (whether command-line options, or printf / system_printf 
format attributes), to warn for formats according to some standard set or 
according to what the system supports - but I don't care for such changes 
in this area at this development stage.

Does some Windows version use these "%I64" formats in inttypes.h without 
supporting the standard "%ll"?  If so there's also the problem that people 
might reasonably use the macros from inttypes.h, even with -pedantic, and 
expect them to work - but if the only Windows versions with inttypes.h 
also supported the standard formats then that header could be fixincluded 
just to use the standard ones.

> + /* This should, in the abstract, be the empty string.  However,
> +    historically, GCC has accepted GLIBC's "I" flag character on all
> +    systems.  */
> + #ifndef TARGET_EXTRA_PRINTF_FLAG_CHARS
> + #define TARGET_EXTRA_PRINTF_FLAG_CHARS "I"
> + #endif

In general, independent of this, we could do with a config/ header shared 
by all glibc systems.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
    jsm@polyomino.org.uk (personal mail)
    joseph@codesourcery.com (CodeSourcery mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)