Fedor Sergeev wrote:
> On Wed, Dec 16, 2009 at 07:41:45AM -0500, James Carlson wrote:
>> Fedor Sergeev wrote:
>>> By the way, as we are likely to revisit -erroff implementation, I would
>>> like to
>>> ask this mailing list - do you have any ideas on -erroff/-errwarn interface
>>> improvement?
>>> Something that you always thought about but were too shy to ask? ;)
>> Not quite on those flags (which seem to work well enough), but there is
>> an old RFE I filed some years ago to allow for better printf/scanf
>> format string versus argument checking.
>
> Eh... thats kind of a huuuge way off the topic :)
It's in the general area of improvements in warnings. ;-}
If you really want strictly erroff/errwarn suggestions, the only one I'd
suggest would be adding hierarchy to the errors, so that I can turn on
and off whole groups of them without having to hunt down all the &^%*&
variations on a theme to cover one issue.
>> It would be nice to have a way to tell the compiler and/or lint that a
>> given function has printf/scanf behavior with some exceptions, and allow
>> the implementor to specify how specifiers and modifiers work for that
>> function.
>
> One of the biggest issues here would be to figure out proper user interface.
> Is there any gcc extension that does something useful for this matter?
> I dont remember one right away.
I don't know of one in gcc, either.
The last time I messed with this was around 17 years ago when I was
working on an embedded system that used gcc for cross-compiles, but I
seem to recall that it internally had a simple static data structure
that described the format specifiers, the allowable modifiers for each,
and the expected argument type.
For our application, I just hacked gcc to update this table (we had "%a"
in the Annex terminal server for printing IP addresses), and maintained
diffs so we could patch each new gcc version as we upgraded. It worked,
but wasn't the cleanest answer. For Sun Studio, I don't have source, so
I can't do this at all.
Turning that mechanism into a string should be fairly straightforward:
"a:#:inaddr_t"
... or some such. I suspect that there won't be gcc compatibility here,
because gcc doesn't give a hoot about the /* PRINTFLIKE */ that Studio
uses anyway, so extending that mechanism shouldn't require substantial
coordination. Hey, maybe it can lead the gcc feature.
I'd suggest this:
/* PRINTFLIKE1 f:: e:: g:: a:#:inaddr_t m::void */
as a way of saying "like printf, but doesn't accept %f, %e, or %g, has
%a with inaddr_t argument and optional # modifier, and has a %m that
takes no argument."
Not a complete spec, by any means, but at least a sketch of the idea.
--
James Carlson 42.703N 71.076W <carlsonj at workingcode.com>
