LWN: Comments on "Enhanced printk() merged" https://lwn.net/Articles/289064/ This is a special feed containing comments posted to the individual LWN article titled "Enhanced printk() merged". en-us Wed, 22 Oct 2025 04:47:26 +0000 Wed, 22 Oct 2025 04:47:26 +0000 https://www.rssboard.org/rss-specification lwn@lwn.net Unescaped characters confuse Konqueror https://lwn.net/Articles/294771/ https://lwn.net/Articles/294771/ corbet Not just "better", it's required to make the page valid HTML. Sorry that one slipped through, it's fixed now. Wed, 20 Aug 2008 14:46:23 +0000 Unescaped characters confuse Konqueror https://lwn.net/Articles/294769/ https://lwn.net/Articles/294769/ Robert The string <tt>printk(" [&lt;%016lx&gt;]</tt> confuses Konqueror (3.5.9) and it terminates the page behind the <tt>&lt;</tt>. It would be better to convert these characters to HTML entities: <tt>&amp;lt;</tt> and <tt>&amp;gt;</tt>. Wed, 20 Aug 2008 14:39:10 +0000 Enhanced printk() merged https://lwn.net/Articles/290505/ https://lwn.net/Articles/290505/ nix <div class="FormattedComment"><pre> 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.) </pre></div> Thu, 17 Jul 2008 17:41:33 +0000 Enhanced printk() merged https://lwn.net/Articles/290469/ https://lwn.net/Articles/290469/ meuh <div class="FormattedComment"><pre> 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: <a href="http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/Target-Format-Checks.html">http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/Target-Format...</a> <a href="http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/Function-Attributes.html#index-Wformat-2132">http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/Function-Attr...</a> </pre></div> Thu, 17 Jul 2008 16:41:53 +0000 Enhanced printk() merged https://lwn.net/Articles/290388/ https://lwn.net/Articles/290388/ nix <div class="FormattedComment"><pre> 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. </pre></div> Thu, 17 Jul 2008 09:56:08 +0000 Enhanced printk() merged https://lwn.net/Articles/290376/ https://lwn.net/Articles/290376/ meuh <p>Strange way to specify format.</p> <p>According to printf() <a href="http://www.opengroup.org/onlinepubs/009695399/functions/printf.html">manual page</a>:</p> <i>Each conversion specification is introduced by the '%' character <em>[...]</em> after which the following appear in sequence: <ul> <li>Zero or more flags </li> <li><em>[...]</em></li> <li>A conversion specifier character that indicates the type of conversion to be applied.</li> </ul> </i> <p> So, the correct way to specify a struct inode pointer should be <b>%Ip</b>, where <b>I</b> is the flag and <b>p</b> the conversion specifier. </p> <p> Did kernel developers read userland manual pages ? :) </p> Thu, 17 Jul 2008 08:59:32 +0000