Enhanced printk() merged

Posted Jul 17, 2008 9:56 UTC (Thu) by nix (subscriber, #2304)
In reply to: Enhanced printk() merged by meuh
Parent article: Enhanced printk() merged

If they used that format, GCC would warn about it. The format chosen looks 
to GCC (as to userland printf()) like a %p with unrelated characters after 
it, so GCC doesn't check those unrelated characters because they're just 
literal text as far as it knows.

to post comments

Enhanced printk() merged

Posted Jul 17, 2008 16:41 UTC (Thu) by meuh (guest, #22042) [Link] (1 responses)

Extending GCC to support some new kind of format string is also possible,
sadly this can't be done dynamically, patching GCC is required.

GCC already knows about other format string, see:
http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/Target-Format...
http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/Function-Attr...

Enhanced printk() merged

Posted Jul 17, 2008 17:41 UTC (Thu) by nix (subscriber, #2304) [Link]

Yes indeed, and printk() is marked up with the printf attribute. The trick 
is to find a way to define new format characters that doesn't cause GCC to 
warn about all of them.

There were attempts in the past to make the format attributes dynamically 
redefinable, but if I recall correctly the consensus in the end was that 
this was simply too damn complicated.

(I wonder if what we need is loose versions of the format attribute's 
archetypes, which warn about incorrect numbers of parameters and type 
mismatches for format letters GCC knows about, but does not check format 
letters that GCC doesn't know? As long as nobody tries to reimplement 
something like .* which changes the number of arguments consumed, this 
should work fine.)