[Top][All Lists]

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

Re: [6/7] Proposed patches to remove several inttypes-related dependenci

From: Bruno Haible
Subject: Re: [6/7] Proposed patches to remove several inttypes-related dependencies
Date: Sun, 24 Apr 2011 18:03:34 +0200
User-agent: KMail/1.9.9

Hi Paul,

> Also, <inttypes.h> no longer defines
> the PRI* and SCN* macros correctly unless the new module
> inttypes-pri-scn is used.  I expect that many programs are like Emacs
> and don't need these these macros or imaxabs etc., so this should be a
> win.
> ...
> > An alternative might be to have a new module, inttypes-h, which provides
> > the shell replacement header, and keep inttypes as the module that pulls
> > in everything C99 related
> Yes, thanks, that would be more backward-compatible.
> Here's a further patch that does that.
> * modules/inttypes-h: New file, containing the old inttypes
> but without the PRI* and SCN* stuff.

I don't think it is a good idea to create more modules than necessary for
a header file. The users then have to understand which one is the best to
choose for them. A 1:1 correspondence between header file and gnulib module,
together with a sound and consistent naming convention (and the documentation)
is how users pick their modules.

We do it for functions like snprintf, though, because code size matters for
some projects: They may just want a simple snprintf that support uses of %d,
nothing fully POSIX compliant. For this reason, we offer modules 'snprintf'
and 'snprintf-posix'.

For header files, the code size argument does not apply, only the amount
of configure checks. A pretty weak argument for separate modules, IMO.

Additionally, in the case of <inttypes.h>, the header file appeared first
in ISO C 99 and got the title "Format conversion of integer types". So,
really, an <inttypes.h> header without PRI* and SCN* macros is nothing we
should offer as an option for gnulib users to pick.

One of the problems with the PRI* and SCN* macros (PRI_MACROS_BROKEN) exists
only on AIX 4. According to Wikipedia <http://en.wikipedia.org/wiki/AIX>, the
successor version, AIX 5.1, is no longer vendor-supported since 5 years ago.
That makes it a good candidate for an obsolete module, similar to the other
proposed patches I posted today. But this removes only PRI_MACROS_BROKEN
from the set of values to be determined at configure time; PRIPTR_PREFIX,
UINT64_MAX_EQ_ULONG_MAX still remain.

In summary, I completely disagree with this patch.

I see two ways of compromising:

a) We could move out the PRI_MACROS_BROKEN to a module inttypes-obsolete.
   But still to be determined at configure time: PRIPTR_PREFIX,
   Would that be acceptable to you?

b) If you reduce the number of inttypes related modules from 3 to 2, and
   the one which produces an incomplete <inttypes.h> file gets a clearly
   discouraging name, such as 'inttypes-incomplete' or 'inttypes-dont-use',
   and that got used only by the 4 function 'imaxabs', 'imaxdiv', 'strtoimax',
   'strtoumax', then I could agree to the refactoring.

In memoriam Siamanto <http://en.wikipedia.org/wiki/Siamanto>

reply via email to

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