[PATCH] crypto/md5: don't depend on stdint

[Paul Eggert]

Here's a simple patch to remove crypto/md5's dependence on
stdint.  It complicates the code in md5.h a bit, but the
result is closer to what's already in glibc.  This will
make it quite a bit easier for Emacs to use crypto/md5.

I haven't pushed this yet.

* lib/md5.h, lib/md5.c:
All uses of uint32_t changed to md5_uint32, as the glibc
version does.
* lib/md5.h: Do not include  unconditionally.
(md5_uint32): New typedef (actually, resurrected from libc).
On ordinary hosts, if not _LIBC, deduce it from .
Default it to  uint32_t on weird hosts.
* modules/crypto/md5 (Depends-on): Remove stdint.
---
 ChangeLog  |   12 +++
 lib/md5.c  |   34 
 lib/md5.h  |   53 +++
 modules/crypto/md5 |1 -
 4 files changed, 73 insertions(+), 27 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index c2c1946..9022e14 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,15 @@
+2011-02-18  Paul Eggert  
+
+   crypto/md5: don't depend on stdint
+   * lib/md5.h, lib/md5.c:
+   All uses of uint32_t changed to md5_uint32, as the glibc
+   version does.
+   * lib/md5.h: Do not include  unconditionally.
+   (md5_uint32): New typedef (actually, resurrected from libc).
+   On ordinary hosts, if not _LIBC, deduce it from .
+   Default it to  uint32_t on weird hosts.
+   * modules/crypto/md5 (Depends-on): Remove stdint.
+
 2011-02-17  Paul Eggert  
 
* NEWS: Mention 2011-02-08 change to stdlib.
diff --git a/lib/md5.c b/lib/md5.c
index d37ca72..e30f0c3 100644
--- a/lib/md5.c
+++ b/lib/md5.c
@@ -82,9 +82,9 @@ md5_init_ctx (struct md5_ctx *ctx)
 
 /* Copy the 4 byte value from v into the memory location pointed to by *cp,
If your architecture allows unaligned access this is equivalent to
-   * (uint32_t *) cp = v  */
+   * (md5_uint32 *) cp = v  */
 static inline void
-set_uint32 (char *cp, uint32_t v)
+set_uint32 (char *cp, md5_uint32 v)
 {
   memcpy (cp, &v, sizeof v);
 }
@@ -109,7 +109,7 @@ void *
 md5_finish_ctx (struct md5_ctx *ctx, void *resbuf)
 {
   /* Take yet unprocessed bytes into account.  */
-  uint32_t bytes = ctx->buflen;
+  md5_uint32 bytes = ctx->buflen;
   size_t size = (bytes < 56) ? 64 / 4 : 64 * 2 / 4;
 
   /* Now count remaining bytes.  */
@@ -255,7 +255,7 @@ md5_process_bytes (const void *buffer, size_t len, struct 
md5_ctx *ctx)
 {
 #if !_STRING_ARCH_unaligned
 # define alignof(type) offsetof (struct { char c; type x; }, x)
-# define UNALIGNED_P(p) (((size_t) p) % alignof (uint32_t) != 0)
+# define UNALIGNED_P(p) (((size_t) p) % alignof (md5_uint32) != 0)
   if (UNALIGNED_P (buffer))
 while (len > 64)
   {
@@ -305,14 +305,14 @@ md5_process_bytes (const void *buffer, size_t len, struct 
md5_ctx *ctx)
 void
 md5_process_block (const void *buffer, size_t len, struct md5_ctx *ctx)
 {
-  uint32_t correct_words[16];
-  const uint32_t *words = buffer;
-  size_t nwords = len / sizeof (uint32_t);
-  const uint32_t *endp = words + nwords;
-  uint32_t A = ctx->A;
-  uint32_t B = ctx->B;
-  uint32_t C = ctx->C;
-  uint32_t D = ctx->D;
+  md5_uint32 correct_words[16];
+  const md5_uint32 *words = buffer;
+  size_t nwords = len / sizeof (md5_uint32);
+  const md5_uint32 *endp = words + nwords;
+  md5_uint32 A = ctx->A;
+  md5_uint32 B = ctx->B;
+  md5_uint32 C = ctx->C;
+  md5_uint32 D = ctx->D;
 
   /* First increment the byte count.  RFC 1321 specifies the possible
  length of the file up to 2^64 bits.  Here we only compute the
@@ -325,11 +325,11 @@ md5_process_block (const void *buffer, size_t len, struct 
md5_ctx *ctx)
  the loop.  */
   while (words < endp)
 {
-  uint32_t *cwp = correct_words;
-  uint32_t A_save = A;
-  uint32_t B_save = B;
-  uint32_t C_save = C;
-  uint32_t D_save = D;
+  md5_uint32 *cwp = correct_words;
+  md5_uint32 A_save = A;
+  md5_uint32 B_save = B;
+  md5_uint32 C_save = C;
+  md5_uint32 D_save = D;
 
   /* First round: using the given function, the context and a constant
  the next context is computed.  Because the algorithms processing
diff --git a/lib/md5.h b/lib/md5.h
index 8b06466..98bcdfc 100644
--- a/lib/md5.h
+++ b/lib/md5.h
@@ -22,7 +22,6 @@
 #define _MD5_H 1
 
 #include 
-#include 
 
 #define MD5_DIGEST_SIZE 16
 #define MD5_BLOCK_SIZE 64
@@ -58,17 +57,53 @@
 extern "C" {
 # endif
 
+/* The following contortions are an attempt to use the C preprocessor
+   to determine an unsigned integral type that is 32 bits wide.  An
+   alternative approach is to use autoconf's AC_CHECK_SIZEOF macro, but
+   doing that would require that the configure script compile and *run*
+   the resulting executable.  Locally running cross-compiled executables
+   is usually not possible.  */
+
+#if defined _LIBC
+# include 
+typedef uint32_t md5_uint32;
+#else
+# if defined __STDC__ && __STDC__
+#  define UINT_MAX_32_BITS 4294967295U
+# else
+#  define UINT_MAX_32_BITS 0xFFF

Re: [PATCH] crypto/md5: don't depend on stdint

[Jim Meyering]

Paul Eggert wrote:
> Here's a simple patch to remove crypto/md5's dependence on
> stdint.  It complicates the code in md5.h a bit, but the
> result is closer to what's already in glibc.  This will
> make it quite a bit easier for Emacs to use crypto/md5.
>
> I haven't pushed this yet.
>
> * lib/md5.h, lib/md5.c:
> All uses of uint32_t changed to md5_uint32, as the glibc
> version does.
> * lib/md5.h: Do not include  unconditionally.
> (md5_uint32): New typedef (actually, resurrected from libc).
> On ordinary hosts, if not _LIBC, deduce it from .
> Default it to  uint32_t on weird hosts.
> * modules/crypto/md5 (Depends-on): Remove stdint.

It's a stylistic regression, but looks safe.
And if it helps emacs use more of gnulib, then I won't object.

However, isn't this just a short-term band-aid?
If emacs later uses the stdint module, much of the justification
for this backwards-seeming change will have disappeared.
Aligning with glibc is less and less valuable, when glibc
maintainers rarely accept patches that would help accommodate.

BTW, nowhere in comments or in the log do you say "why" you're making
this change.  Since it could be seen as a regression-inducing change,
including justification (like your first paragraph) in the log would help.
Adding a comment in the source might help, too, if someone searches for
ifdef'd stdint.h inclusions and finds those two.

Using ChangeLog style commit logs is fine for nitty gritty details,
but IMHO, we should make a point of justifying each change, too,
when that's not obvious from the rest of a log entry.

Re: [PATCH] crypto/md5: don't depend on stdint

[Bruno Haible]

Paul Eggert wrote:
> Here's a simple patch to remove crypto/md5's dependence on
> stdint.  It complicates the code in md5.h a bit

35 lines of code to define a type md5_uint32, that is only used in
md5.h? That's a step backwards to where we were before gnulib. The
benefit of gnulib is that we can program according to ISO C 99 and
POSIX, and our code is not littered with auxiliary code for various
deficient platforms.

> but the result is closer to what's already in glibc.

The code in glibc was written to be reusable before gnulib came along.
When we simplified the code in gnulib on 2005-10-17, we also asked to
sync glibc, but Ulrich did not want this:
.
IMO this is not sufficient reason to change gnulib back to where we were
before.

> This will make it quite a bit easier for Emacs to use crypto/md5.

Since this is only for Emacs, I'd prefer if these modifications were
stored in the Emacs repository only, as files
  gnulib-local/lib/md5.h.diff
  gnulib-local/lib/md5.c.diff
where they can be automatically be taken into account by gnulib-tool's
--local-dir option.

Bruno
-- 
In memoriam Khosrow Golsorkhi 

Re: removing stdint's dependency on wchar

[Bruno Haible]

Hi Paul,

> md5 includes stdint.h for uint32_t, and the stdint
> module depends on wchar for WCHAR_MIN etc; but md5 does
> not need WCHAR_MIN etc.
>
> Here's a proposed patch to make stdint configure faster,
> primarily by removing its dependency on wchar.

I think this patch would make gnulib harder to use. So far, it's easy
to remember: "I want a working stdint.h - so I need module stdint
(or stdint-posix if that exists)". It should stay like this.

Instead I would suggest that you create a new module that provides less
guarantees than the 'stdint' module, and let 'md5' depend on that.

Two candidates come to mind:
  a) A module 'stdint-simple' that deals only with the types int*, uint*
 and their respective macros, but not with ptrdiff_t, sig_atomic_t,
 wchar_t, wint_t.
  b) A module 'stdint-types' that guarantees the types of 
 but not their respective macros.

The 'stdint' module would then depend on that module, and in m4/stdint.m4
there would be two entry points gl_STDINT_H and gl_STDINT_H_SIMPLE or
gl_STDINT_H_TYPES.

Bruno
-- 
In memoriam Khosrow Golsorkhi 

Re: new module 'setlocale'

[Eric Blake]

On 02/17/2011 08:23 PM, Bruno Haible wrote:
> 
> Huh? This is surprising. And what does this program show?
> 
> #include 
> #include 
> #include  
> #include 
> 
> int
> main ()
> {
>   setenv ("LC_ALL", "ar_SA.ISO-8859-1", 1);
>   if (setlocale (LC_ALL, "") != NULL)
> {
>   printf ("%s\n", setlocale (LC_ALL, NULL));
>   printf ("%s\n", setlocale (LC_CTYPE, NULL));
> }
>   return 0;
> }

Here, the output is:

C
C

-- 
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] longlong: tune, particularly for common case of c99

[Eric Blake]

On 02/16/2011 02:26 AM, Paul Eggert wrote:
> I'm now looking to incorporate the crypto/md5 module into Emacs,
> and trying to slim down its 'configure'.  Here's one: if it's
> C99 we don't have to test for 'long long' separately.  Also,
> in practice, if there's no 'unsigned long long', there's no 'long long'.
> I installed this into gnulib, and will put a similar change into
> Autoconf.

This causes a regression when cross-compiling:

checking for long long int... configure: error: in
`/home/remote/eblake/libvirt-tmp/build':
configure: error: cannot run test program while cross compiling
See `config.log' for more details

I'm trying to diagnose it further, but we may need to revert this change
if I can't figure out why and how to fix it.

-- 
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

[PATCH] longlong: skip, rather than fail, on cross-compilation

[Eric Blake]

* m4/longlong.m4 (AC_TYPE_LONG_LONG_INT): Avoid aborting configure
when cross-compiling; regression from 2011-02-16.

Signed-off-by: Eric Blake 
---

It turned out to be a simple fix (an empty 4th argument is fatal,
so to skip cross-compilation, you have to provide an explicit
no-op argument).  Pushing this to gnulib, and the similar patch
to autoconf.

 ChangeLog  |6 ++
 m4/longlong.m4 |5 +++--
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index c2c1946..fad8587 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2011-02-18  Eric Blake  
+
+   longlong: skip, rather than fail, on cross-compilation
+   * m4/longlong.m4 (AC_TYPE_LONG_LONG_INT): Avoid aborting configure
+   when cross-compiling; regression from 2011-02-16.
+
 2011-02-17  Paul Eggert  

* NEWS: Mention 2011-02-08 change to stdlib.
diff --git a/m4/longlong.m4 b/m4/longlong.m4
index 04c8303..aed816c 100644
--- a/m4/longlong.m4
+++ b/m4/longlong.m4
@@ -1,4 +1,4 @@
-# longlong.m4 serial 15
+# longlong.m4 serial 16
 dnl Copyright (C) 1999-2007, 2009-2011 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
@@ -45,7 +45,8 @@ AC_DEFUN([AC_TYPE_LONG_LONG_INT],
}
  return 0;]])],
 [],
-[ac_cv_type_long_long_int=no])
+[ac_cv_type_long_long_int=no],
+[:])
 fi
   fi])
   if test $ac_cv_type_long_long_int = yes; then
-- 
1.7.4

Re: removing stdint's dependency on wchar

[Paul Eggert]

On 02/18/2011 03:25 AM, Bruno Haible wrote:

Instead I would suggest that you create a new module that provides less
guarantees than the 'stdint' module, and let 'md5' depend on that.


I considered that, but the most logical candidate for a stdint
subset module is "all of stdint except for WINT_MIN, WINT_MAX,
WCHAR_MIN, and WCHAR_MAX".  If we called this module
"stdint-sans-wchar", say, then every
occurrence of "stdint" in gnulib/modules/* should be
replaced by "stdint-sans-wchar".  And I expect this to
be true for nearly every project that uses Gnulib.

This suggests that we should use the name "stdint" for the
common case, and some other name for the rare case of
applications that need WINT_MIN etc.  It'd be easy to
create a module "stdint-with-wchar" to do that, based
on the patch I already sent: simply have a dummy module
that depends on both stdint and wchar.  But the name
"stdint-with-wchar" sounds rather ad hoc.  And really
perhaps it is simpler just to say that if you need the
wchar stuff then use the wchar module too (which you'll
probably be doing anyway, so it's no big deal).  This is
what stdlib already does with random_r.

Re: removing stdint's dependency on wchar

[Paul Eggert]

On 02/18/2011 03:25 AM, Bruno Haible wrote:


it's easy to remember: "I want a working stdint.h -
so I need module stdint  or stdint-posix if that exists)".


It'd be nice if it were that easy, but unfortunately it's not.

In the old days, when one needed a working uint32_t, one
would just invoke AC_TYPE_UINT32_T or something like that.
There were problems with that approach, but it had one
major advantage: one didn't drag in all sorts of tests
for things like wint_t that one doesn't need.

I'd like to resurrect that old advantage, if possible.
Gnulib deservedly has the reputation of too many dependencies,
and this is inhibiting its use in other projects (not just
Emacs).  If we can break the dependencies at a relatively
small cost, we should do that.

One way to attack this particular issue would be to have
a new module, uint32_t say, that just supplies  the
uint32_t feature.  That is, it arranges for a stdint.h that
defines uint32_t, but the stdint.h might not be good for
anything else.

That would be overkill, though.  The stdint module defines
waaayy too many features and it would be a big pain to write
a separate module for each one.  And it's not like stdint is
unique in this respect; we have other modules such as stdlib
that define many features.  What we've done in the past is
take a pragmatic approach: we support all the features that
are generally needed by a stdlib's users or are easy to
support, but when there's a definite cost for a feature that
hardly anybody uses, we partition it off into an extra module.

That's what's needed for stdint.  Hardly anybody needs its
WINT_MAX and WCHAR_MAX features, so it makes sense to
partition them off.  We don't insist that stdbool mimic
C99 bool exactly, only "well enough"; and similarly we don't
need to insist that stdint mimic C99 stdint.h exactly.

Re: removing stdint's dependency on wchar

[Eric Blake]

On 02/18/2011 01:56 PM, Paul Eggert wrote:
> This suggests that we should use the name "stdint" for the
> common case, and some other name for the rare case of
> applications that need WINT_MIN etc.  It'd be easy to
> create a module "stdint-with-wchar" to do that, based
> on the patch I already sent: simply have a dummy module
> that depends on both stdint and wchar.  But the name
> "stdint-with-wchar" sounds rather ad hoc.  And really
> perhaps it is simpler just to say that if you need the
> wchar stuff then use the wchar module too (which you'll
> probably be doing anyway, so it's no big deal).  This is
> what stdlib already does with random_r.

Well, using  to get random_r is not standardized (we only
provided it for glibc compatibility, so it makes sense to make that
dependent on random_r), whereas the wchar_t stuff is standardized.

On the other hand, I agree that W{CHAR,INT}_{MAX,MIN} are unlikely to be
useful unless you are also using w{char,int}_t as defined by some other
header.

I'm perfectly fine with stdint being the simpler module, and
stdint+wchar being the complete replacement header.  I don't even know
that we need a stdint-with-wchar module.

-- 
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] crypto/md5: don't depend on stdint

[Paul Eggert]

On 02/18/2011 03:13 AM, Bruno Haible wrote:


35 lines of code to define a type md5_uint32, that is only used in
md5.h?


I used 35 lines because that's what glibc uses.  I can easily shrink
it to 8 lines, since we assume C89 or better:

/* Prefer 'unsigned int' for the benefit of typical pre-C99 hosts.  */
#include 
#if UINT_MAX == 4294967295u
typedef unsigned int md5_uint32;
#else
# include 
typedef uint32_t md5_uint32;
#endif



Since this is only for Emacs, I'd prefer if these modifications were
stored in the Emacs repository only, as files
   gnulib-local/lib/md5.h.diff
   gnulib-local/lib/md5.c.diff
where they can be automatically be taken into account by gnulib-tool's
--local-dir option.


In the long term it'd be simpler to drop my idea, if the above
8 lines are unacceptably long, and instead just have Emacs start using
stdint now.  That will drag in more stuff than I'd like, and
will cause some problems on the Emacs side (I got complaints
about the stdlib stuff when I imported getloadavg), but perhaps
it'll be doable.

There is a tradeoff here between breaking dependencies, which is
good, and writing clear and clean code to standards, which is
also good.  In this particular case I'm hoping that the benefit
of breaking the dependency is worth the cost of adding 8 lines
or so of code.

Re: removing stdint's dependency on wchar

[Bruno Haible]

Hi Paul,

At the beginning of this thread, you made this statement:

> The problem is
> that md5 includes stdint.h for uint32_t, and the stdint
> module depends on wchar for WCHAR_MIN etc; but md5 does
> not need WCHAR_MIN etc.

It's easy to get this impression. But no, 'stdint' does not depend on 'wchar'
for WCHAR_MIN etc. It depends on 'wchar' out of pure commodity.

Look at the git history:

  - On 2006-06-26, we found out that for getting WCHAR_MIN, WCHAR_MAX one
needs to include  on some systems. I think these systems are
AIX 4.3.2, HP-UX 11.11, Interix 3.5, OSF/1, and BSDI.




  - Later, on 2007-01-06, we had a working 'wchar' module, and decided
to use it everywhere, to remove the use of @HAVE_WCHAR_H@:




So, in order to break the dependency, we only need to revert a small part
of the 2007-01-06 patch.

Here's the proposed patch. It does not modify the promises made by the 'stdint'
module. It also is much smaller and does not require the creation of a separate
module.


2011-02-18  Bruno Haible  

stdint: Cut dependency to module 'wchar'.
* lib/stdint.in.h: Include wchar.h only when HAVE_WCHAR_H is 1. Also
include the necessary prerequisites.
* m4/stdint.m4 (gl_STDINT_H): Test whether wchar.h exists.
* modules/stdint (Depends-on): Remove wchar.
(Makefile.am): Substitute HAVE_WCHAR_H.
This reverts part of a 2007-01-06 commit. Reported by Paul Eggert.

--- lib/stdint.in.h.origSat Feb 19 01:46:42 2011
+++ lib/stdint.in.h Sat Feb 19 01:44:49 2011
@@ -497,7 +497,12 @@
sequence of nested includes
 ->  ->  -> , and the latter includes
 and assumes its types are already defined.  */
-#if ! (defined WCHAR_MIN && defined WCHAR_MAX)
+#if @HAVE_WCHAR_H@ && ! (defined WCHAR_MIN && defined WCHAR_MAX)
+  /* BSD/OS 4.0.1 has a bug: ,  and  must be
+ included before .  */
+# include 
+# include 
+# include 
 # define _GL_JUST_INCLUDE_SYSTEM_WCHAR_H
 # include 
 # undef _GL_JUST_INCLUDE_SYSTEM_WCHAR_H
--- m4/stdint.m4.orig   Sat Feb 19 01:46:42 2011
+++ m4/stdint.m4Sat Feb 19 01:42:38 2011
@@ -1,4 +1,4 @@
-# stdint.m4 serial 37
+# stdint.m4 serial 38
 dnl Copyright (C) 2001-2011 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
@@ -27,6 +27,15 @@
   fi
   AC_SUBST([HAVE_UNSIGNED_LONG_LONG_INT])
 
+  dnl Check for , in the same way as gl_WCHAR_H does.
+  AC_CHECK_HEADERS_ONCE([wchar.h])
+  if test $ac_cv_header_wchar_h = yes; then
+HAVE_WCHAR_H=1
+  else
+HAVE_WCHAR_H=0
+  fi
+  AC_SUBST([HAVE_WCHAR_H])
+
   dnl Check for .
   dnl AC_INCLUDES_DEFAULT defines $ac_cv_header_inttypes_h.
   if test $ac_cv_header_inttypes_h = yes; then
--- modules/stdint.orig Sat Feb 19 01:46:42 2011
+++ modules/stdint  Sat Feb 19 01:45:53 2011
@@ -14,7 +14,6 @@
 Depends-on:
 include_next
 multiarch
-wchar
 
 configure.ac:
 gl_STDINT_H
@@ -36,6 +35,7 @@
  -e 's/@''HAVE_INTTYPES_H''@/$(HAVE_INTTYPES_H)/g' \
  -e 's/@''HAVE_SYS_INTTYPES_H''@/$(HAVE_SYS_INTTYPES_H)/g' \
  -e 's/@''HAVE_SYS_BITYPES_H''@/$(HAVE_SYS_BITYPES_H)/g' \
+ -e 's/@''HAVE_WCHAR_H''@/$(HAVE_WCHAR_H)/g' \
  -e 's/@''HAVE_LONG_LONG_INT''@/$(HAVE_LONG_LONG_INT)/g' \
  -e 
's/@''HAVE_UNSIGNED_LONG_LONG_INT''@/$(HAVE_UNSIGNED_LONG_LONG_INT)/g' \
  -e 's/@''APPLE_UNIVERSAL_BUILD''@/$(APPLE_UNIVERSAL_BUILD)/g' \

-- 
In memoriam Khosrow Golsorkhi 

Re: removing stdint's dependency on wchar

[Bruno Haible]

Paul Eggert wrote:
> This suggests that we should use the name "stdint" for the
> common case, and some other name for the rare case of
> applications that need WINT_MIN etc.  It'd be easy to
> create a module "stdint-with-wchar" to do that

I disagree that "common" vs. "rare" should be guiding criterion here.

It's more important that a user gets a fully correct and fully POSIX
compliant  when he asks for the module name that most immediately
comes to mind, namely 'stdint'. Looking for a module with fewer dependencies
is optimization. It's OK that for optimizating you need to investigate a
little more the available set of modules, until you find 'stdint-sans-wchar'.

We use this approach already for the modules 'strstr' and 'strstr-simple'.

Bruno
-- 
In memoriam Khosrow Golsorkhi 

Re: breaking dependencies

[Bruno Haible]

Hi Paul, all,

> If we can break the dependencies at a relatively
> small cost, we should do that.

Yes, that's what Sam Steingold has been asking for, for years.

The costs that I can see are two-fold:

  1) Additional modules; users have to read some documentation
 before they can decide whether they need, say, 'strstr' or
 'strstr-simple'.

  2) When we duplicate a workaround idiom in several files, and the
 workaround has to be extended, it's easy to miss some of
 the occurrences of the idiom. For example, for including
 , we did

   #include 
   #include 

 and then later discovered that we need to write

   #include 
   #include 
   #include 
   #include 

 and then again later found out that we need to write

   #include 
   #include 
   #include 
   #include 
   #include 

> What we've done in the past is
> take a pragmatic approach: we support all the features that
> are generally needed by a stdlib's users or are easy to
> support, but when there's a definite cost for a feature that
> hardly anybody uses, we partition it off into an extra module.

Yup. And our estimation has been that code size is a cost -
which is why 'snprintf-posix' is a separate module from 'snprintf' -
but that .h files and .m4 macros come at virtually no cost.

Bruno
-- 
In memoriam Khosrow Golsorkhi 

Re: removing stdint's dependency on wchar

[Paul Eggert]

On 02/18/2011 04:52 PM, Bruno Haible wrote:
> Here's the proposed patch. It does not modify the promises made by the 
> 'stdint'
> module. It also is much smaller and does not require the creation of a 
> separate
> module

Thanks, that solves the problem for me with Emacs, and it's
simpler than my patch.  I pushed it in your name.

Give your and Jim's qualms about the md5 change, I'll see
if the Emacs folks will take md5 with this new stdint,
and if that works then we won't need the md5 change.
We can always fall back on the md5 change if it doesn't
work.

[PATCH] stdint: omit redundant check for wchar.h

[Paul Eggert]

* m4/stdint.m4 (gl_STDINT_H): The earlier part of this macro now
always tests whether wchar.h exists, so remove the now-redundant test.
diff --git a/m4/stdint.m4 b/m4/stdint.m4
index 2b67952..e7d0d07 100644
--- a/m4/stdint.m4
+++ b/m4/stdint.m4
@@ -1,4 +1,4 @@
-# stdint.m4 serial 38
+# stdint.m4 serial 39
 dnl Copyright (C) 2001-2011 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
@@ -301,10 +301,6 @@ static const char *macro_values[] =
 fi
 AC_SUBST([HAVE_SYS_BITYPES_H])

-dnl Check for  (missing in Linux uClibc when built without wide
-dnl character support).
-AC_CHECK_HEADERS_ONCE([wchar.h])
-
 gl_STDINT_TYPE_PROPERTIES
 STDINT_H=stdint.h
   fi