Kernel printk format string compression: C syntax problem

Kernel printk format string compression: C syntax problem

[Timothy Miller]

Some of you may recall that I've been working on a way to compress 
kernel printk format strings so as to shrink the kernel memory image a 
bit.  My results so far are that given the amount of space required for 
all kernel strings, I can compress them to half their original size. 
Given something the size of an allyesconfig kernel, that's not much 
compression over-all, but it's still interesting.  Additionally, the 
means to compress the kernel messages are a compile-time issue and 
completely transparent to the coder.

I am, however, encountering a problem, and I was hoping some people who 
know C syntax better than both myself and the C syntax spec I found at 
"http://eic.sourceforge.net/iso_c.html" could help me solve it.

Here's an example of the problem:

This line from process.c starts out as:

printk("EIP: %04x:[<%08lx>] CPU: %d\n",0xffff & regs->xcs,regs->eip, 
(current_thread_info()->cpu));

And is replaced by:

printk( "EIP\200\3164x:[<\3168lx>] CPU\200%d\n" ,0xffff & 
regs->xcs,regs->eip, (current_thread_info()->cpu));

GCC 3.0.4 makes the following complaint:

arch/i386/kernel/process.c:173: warning: too many arguments for format

What I believe is happening is that where I have the escape code "\316" 
concatenated with the literal "8", the compiler is seeing it as "\3168" 
and doesn't want to take it.  Now, it's just a warning, and it MAY be 
doing the right thing, but what I want to know is the PROPER UNAMBIGUOUS 
way to specify at 3-digit octal escape code which is followed 
immediately by a literal digit.

Any suggestions?

Thank you.

Re: Kernel printk format string compression: C syntax problem

[Bryan O'Sullivan]

On Fri, 2003-06-06 at 10:27, Timothy Miller wrote:

> printk( "EIP\200\3164x:[<\3168lx>] CPU\200%d\n" ,0xffff & 
> regs->xcs,regs->eip, (current_thread_info()->cpu));
> 
> GCC 3.0.4 makes the following complaint:
> 
> arch/i386/kernel/process.c:173: warning: too many arguments for format
> 
> What I believe is happening is that where I have the escape code "\316" 
> concatenated with the literal "8", the compiler is seeing it as "\3168" 
> and doesn't want to take it.

No.  Look at the __attribute__ on printk in include/linux/kernel.h.  GCC
believes that printk takes a printf-style format string as its first
argument, but you've mangled the string so that the number of format
specifiers doesn't match the number of arguments.

	<b

Re: Kernel printk format string compression: C syntax problem

[Timothy Miller]

Bryan O'Sullivan wrote:

> 
> 
> No.  Look at the __attribute__ on printk in include/linux/kernel.h.  GCC
> believes that printk takes a printf-style format string as its first
> argument, but you've mangled the string so that the number of format
> specifiers doesn't match the number of arguments.
> 


Oh!  So GCC is trying to be smart about printf format strings?  Cool. 
Never mind then.  :)

Re: Kernel printk format string compression: C syntax problem

[Timothy Miller]

Richard B. Johnson wrote:

> 
> Aren't octal values supposed to always start with '0'? I remember
> this from some formal training when 'C' replaced Pascal. The
> second "printf()" should __not__ TAB over the text. With GNU
> gcc, it does. This doesn't mean that it's "correct", only that
> GNU does it that way.
> 

Octal values start with '0' when they're numerical values.  When they're 
in strings as escape characters, the C syntax is "\nnn".  Every 
reference I find says that.  Some script languages, however require that 
octal values start with '0' in strings, so csh would expect to see "\0nnn".

Additionally, when I compile in the dictionary into the program that
does the string replacement, I get no complaints, although every
character in there is "\nnn".

Re: Kernel printk format string compression: C syntax problem

[Richard B. Johnson]

On Fri, 6 Jun 2003, Timothy Miller wrote:

>
>
> Richard B. Johnson wrote:
>
> >
> > Aren't octal values supposed to always start with '0'? I remember
> > this from some formal training when 'C' replaced Pascal. The
> > second "printf()" should __not__ TAB over the text. With GNU
> > gcc, it does. This doesn't mean that it's "correct", only that
> > GNU does it that way.
> >
>
> Octal values start with '0' when they're numerical values.  When they're
> in strings as escape characters, the C syntax is "\nnn".  Every
> reference I find says that.  Some script languages, however require that
> octal values start with '0' in strings, so csh would expect to see "\0nnn".
>
> Additionally, when I compile in the dictionary into the program that
> does the string replacement, I get no complaints, although every
> character in there is "\nnn".
>

So why the hell did you forward this to linux-kernel when I answered
you privately?

Re: Kernel printk format string compression: C syntax problem

[Timothy Miller]

Richard B. Johnson wrote:
> 
> 
> So why the hell did you forward this to linux-kernel when I answered
> you privately?
> 
> 

OH!  My sincere apologies.  I have the tendency to hit "Reply" instead 
of "Reply All", and so often when replying to a list posting, I have to 
manually enter the lkml address.  When I didn't see lkml in the 
recipient list, I just assumed that I had hit the wrong button again.

I would never have done this intentionally.