printflike vs kprintflike

Neal Fachan neal at isilon.com
Fri May 6 12:44:17 PDT 2005


On Thu, May 05, 2005 at 02:55:10AM +0000, Alexander Kabaev wrote:
> On Wed, May 04, 2005 at 06:16:06PM -0400, Jeff Roberson wrote:
> > I have a patch from Neal Fachan of isilon that implements a new gcc
> > attribute 'kprintflike' that is used in place of 'printflike' in the
> > kernel.  This is done to stop us from leaking kernel printf formats into
> > userspace.  Apparently -fformat-extensions is broken in gcc3.  This also
> > stops our formats from leaking into any other custom formats defined in
> > gcc.
> > 
> 
> I would like to avoid introduction of a new printf attribute if possible.
> Does fixed -fformat-extensions suffice your needs? If so, can you try the
> patch below instead?

I assume that you're interested in not changing all the __printflike's
to __kprintflike's? That seems like a good goal, and it certainly eases
upgrading.

The are a few problems with your patch. First, as Bruce points out,
there are other differences between the kernel's printf and userspace's
printf. One difference is that the floating point formats aren't
supported. Another is that some of the flags are different (' ' isn't
supported, for example).

The second problem is the explicit checks for 'b' and 'D' later in
check_format_info_main. These checks remove the first argument (of two)
for these format specifiers. However, if there is another format
type which also uses either of these characters, there will be a
conflict (strftime's %D, for example).

How about the approach of having two different format tables
(format_kind_info's), one for kprintf and one for printf, and then
choosing the appropriate one based on the flag_format_extensions? I'll
code something up today and send a patch.

Thanks.

-Neal

-- 
Neal Fachan
neal at isilon.com


More information about the freebsd-arch mailing list