Re: formats and syslog question

["Joseph S. Myers" <jsm28 at cam dot ac dot uk>]

On Fri, 13 Sep 2002, Daniel Jacobowitz wrote:

> On Fri, Sep 13, 2002 at 02:12:05PM +0200, Marc Espie wrote:
> > Okay. I'm just going to look at adding a 'syslog' format, then.
> > Rationale: there are precious few portable formats, even in single unix.
> > And format checking is very, very useful in finding some classes of bugs.
> > Now, considering syslog(), you can very easily see that such bugs can be
> > critical very easily, as syslog() tends to be encountered in daemons and
> > such.

I don't think duplicating all the printf format specification with a few
changes is the right interim solution for this for the FSF tree (though of
course you can do it in another tree).  A better interim solution would be
to implement fine-grained warning control (which has many other uses) so
users of -pedantic can disable the warning for %m only.  (This would of
course need to be a version of warning control that allows disabling the
warning just for "warning: ISO C does not support the `%m' printf format"  
and not for similar warnings with other formats than %m specified - one
based on the final message text would work, one based on an assigned
identifier for each message would not.)

> Well, if you have an idea on a syntax for more extensible format
> checking, as Joseph mentioned above, it'd be much nicer if you want
> down that path.  For instance, Linux's printk() would very much like to
> have format checking, but it can't at the moment because it has some
> custom specifiers.

Rather, it would like to have custom specifiers but can't because of the
nonextensibility.  The same applies to GCC's diagnostic functions.

Any good extensible system should allow any of the standard formats to be
specified fully by a user, or a named standard format to be varied
arbitrarily by a user (adding, changing or taking away specifiers and
modifiers and flags, ...).  It also needs not to suffer from closely
exposing GCC's internal data structures so they can't then readily be
changed in future.  (It has been stated
<http://gcc.gnu.org/ml/gcc/2000-12/msg00317.html> that Red Hat has an
extensible format checking implementation, but the description there (I
haven't seen any documentation for it) doesn't make it look satisfactory
and nor does the regular expression approach given in that message as an
alternative seem reasonable in terms of describing the actual structure of
format strings and what's checked.)

-- 
Joseph S. Myers
jsm28@cam.ac.uk