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
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
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 p
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 hard
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",
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
* 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). Pus
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_M
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
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 se
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
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
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 cri
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 whet
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
* 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 se
16 matches
Mail list logo
