bug-gnulib
[Top][All Lists]
Advanced

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

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


From: Jim Meyering
Subject: Re: [PATCH] crypto/md5: don't depend on stdint
Date: Fri, 18 Feb 2011 10:02:18 +0100

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 <stdint.h> unconditionally.
> (md5_uint32): New typedef (actually, resurrected from libc).
> On ordinary hosts, if not _LIBC, deduce it from <limits.h>.
> Default it to <stdint.h> 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.



reply via email to

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