This is the mail archive of the
mailing list for the GCC project.
Re: Patch to check asm_fprintf format specifiers [take 2]
> From: "Joseph S. Myers" <email@example.com>
> 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?
> > 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?
Kaveh R. Ghazi firstname.lastname@example.org