Re: Patch to check asm_fprintf format specifiers [take 2]

["Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>]

 > From: "Joseph S. Myers" <jsm28@cam.ac.uk>
 > 
 > On Sat, 31 May 2003, Kaveh R. Ghazi wrote:
 > 
 > > Since the hook doesn't require a new language construct the situation
 > > described in the previous thread, where a new GCC removes this feature
 > > in favor of real extensible checking and then proceeds to try and
 > > compile older GCC releases with this checking style and fails to parse
 > > it, should not arise.  So I'm going to suggest that we leave this in
 > 
 > Is your point that unknown format types are just warnings, not errors,
 > that this is deliberate, and releases have -Werror disabled?

Yes, exactly.


 > > Regarding a testcase, I'm currently in the process of
 > > designing/creating one.  However I recently posted a patch for
 > > updating the internals of asm_fprintf to fix broken and/or add missing
 > > specifiers.  Until that settles down and/or is accepted/rejected, I'd
 > > prefer to submit the testcase separately.
 > 
 > Regarding that previous patch, where specifiers are missing/broken are
 > they ones that are actually used in parts of GCC that expect them to work?  
 > (Since there is no need for asm_fprintf to implement C90 specifiers just
 > for the sake of it, unless some code in GCC using asm_fprintf wants to use
 > them.)  Likewise, are the specifiers currently implemented all used?  In
 > particular, does any use of asm_fprintf actually use floating point
 > specifiers or %p, which this patch includes as supported?

I looked and I'm not seeing any places in GCC that use %p, or the FP
specifiers, but my grep could have missed it.  The float ones look
like they're implemented correctly, but %p is definitely buggy and %c
and %ll are missing.

I don't have a strong opinion whether we fix them, or take them out /
leave them unimplemented.  Of mild concern is if we take them out and
then have to add them back because a later GCC version decides they
are needed.  That'll cause version skew because the host compiler's
notion of what's correct will differ from that of the compiler being
built.  So I lean towards having more implemented rather than less.

IMHO this is orthogonal to the checking patch itself.  We can
reconcile the formal checks vs what's actually accepted by asm_fprintf
incrementally once the overall scheme is approved and installed.
That's why I deferred the testcase.  But I do intend to reconcile them
if that's your worry.

Do you think the patch is ok?

		Thanks,
		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu