bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Printf for gnulib?


From: Bruno Haible
Subject: Re: Printf for gnulib?
Date: Tue, 20 Feb 2007 04:23:21 +0100
User-agent: KMail/1.5.4

Daniel Jacobowitz and Ben Pfaff wrote:
> > Is there any interest in a full C99 printf in gnulib?  Right now,
> > there's snprintf, vasnprintf, vasprintf, vsnprintf, and xvasprintf.
> > The problem with these is that they punt to the system's underlying
> > printf for some things.  That's an issue e.g. with Windows's %I64d
> > versus %lld, and with C99 formats like %a.
> 
> I'd be very pleased to have a full C99 printf in gnulib, mainly
> because I'm getting tired of not being able to write %zu to print
> a size_t.

A full C99 printf is not enough for internationalized programs, since it
doesn't support argument reordering through the "%m$" syntax. Therefore I'm
in favour of targetting directly POSIX:2001 (it's a superset of C99 printf).

Am I understanding it right, that for POSIX support, compared to what all
systems already provide, we need:
  1) support for "ll", "z", ... size flags,      [mingw]
  2) support for "%m$" reordering,               [mingw, NetBSD, older cygwin]
  3) support of "%n",                            [HP-UX]
  4) support for "a", "A" conversion,            [?]
  5) correct return value of snprintf            [HP-UX at least]
?

The goal of the gnulib *printf modules, so far, has been to provide the
particular function if it is missing. vasnprintf already does part of the
POSIX functionality because, historically, I borrowed the implementation
from GNU gettext, which had 1), 2), and 3) already implemented.

I agree that gnulib should offer POSIX compliant *printf functions. However,
since just having the function _at_all_, without requiring full POSIX,
has been good enough for many packages, and vasnprintf.c is a big chunk of
code that many people probably don't want to see added to every executable
unless absolutely necessary, I would like that gnulib proposes two offers:

  (A) The "minimal" offer: just ensure that the function exists.
      Modules: snprintf, vsnprintf,
               asprintf, vasprintf.

  (B) Full POSIX offer: override the system functions if they are not POSIX
      compliant.
      Modules: snprintf-posix, vsnprintf-posix,
               sprintf-posix, vsprintf-posix,
               fprintf-posix, vfprintf-posix,
               printf-posix, vprintf-posix,
               asprintf-posix, vasprintf-posix.

This dual offer is similar to what we do with "fnmatch-posix" and
"fnmatch-gnu".

I include [v]asprintf in this list, because although it's not a POSIX function,
NetBSD has asprintf but it does not support POSIX format strings ( 2) missing).

With this offer, everyone should be served, I think?

Bruno





reply via email to

[Prev in Thread] Current Thread [Next in Thread]