From owner-freebsd-arch@FreeBSD.ORG Thu May 5 09:04:34 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D818816A4CE; Thu, 5 May 2005 09:04:34 +0000 (GMT) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3ED6443DAC; Thu, 5 May 2005 09:04:34 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86])j4594MkG023144; Thu, 5 May 2005 19:04:22 +1000 Received: from epsplex.bde.org (katana.zip.com.au [61.8.7.246]) j4594Kx7005348; Thu, 5 May 2005 19:04:21 +1000 Date: Thu, 5 May 2005 19:04:21 +1000 (EST) From: Bruce Evans X-X-Sender: bde@epsplex.bde.org To: Alexander Kabaev In-Reply-To: <20050505025509.GA3120@freefall.freebsd.org> Message-ID: <20050505184727.A1664@epsplex.bde.org> References: <20050504180112.M18611@mail.chesapeake.net> <20050505025509.GA3120@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: arch@freebsd.org Subject: Re: printflike vs kprintflike X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2005 09:04:35 -0000 On Thu, 5 May 2005, 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? -fformat-extensions was intended for this. > Index: c-common.h > =================================================================== > RCS file: /home/ncvs/src/contrib/gcc/c-common.h,v > retrieving revision 1.7 > diff -u -r1.7 c-common.h > --- c-common.h 28 Jul 2004 03:46:02 -0000 1.7 > +++ c-common.h 5 May 2005 02:45:10 -0000 > @@ -840,6 +840,9 @@ > /* Nonzero means the expression being parsed will never be evaluated. > This is a count, since unevaluated expressions can nest. */ > > +/* Nonzero allows FreeBSD kenrel-specific printf formats. */ Spelling. > +extern int flag_format_extensions; > + > extern int skip_evaluation; > > /* C types are partitioned into three subsets: object, function, and > Index: c-format.c > =================================================================== > RCS file: /home/ncvs/src/contrib/gcc/c-format.c,v > retrieving revision 1.9 > diff -u -r1.9 c-format.c > --- c-format.c 28 Jul 2004 03:57:21 -0000 1.9 > +++ c-format.c 5 May 2005 02:33:31 -0000 > @@ -257,7 +257,8 @@ > STD_C94, > STD_C9L, /* C99, but treat as C89 if -Wno-long-long. */ > STD_C99, > - STD_EXT > + STD_EXT, > + STD_BSD > }; > > /* The C standard version C++ is treated as equivalent to -fformat-extensions was also intended to unextend (sic) to the formats that are actually supported by the kernel printf. I never got around to implementing this. It is now easier to implement, but not as easy as it should be (the enums in the above should be bitmaps ...). The kernel printf doesn't support floating point formats, at least, and shouldn't support mistakes like %q and %ll. Bruce