Re: [Bug-gnulib] strftime merge from Emacs

[Paul Eggert]

Dave Love <address@hidden> writes:

> That said, I don't disagree about dropping K&R support, at least as
> far as the compiler (rather than the library) goes.  Do you assume a
> standard-conforming libc without problems?

No, we're more cautious about that.  We merely assume freestanding C89
or better.  I.e., we assume that everything in <float.h>, <limits.h>,
<stdarg.h>, and <stddef.h> works, but we don't assume the other
headers all work.  That way, we still support SunOS 4.x, once GCC is
installed there.

> >> Anyhow, I'll ask the question about K&R again.
> >
> > Did you get an answer back?
> 
> He asked me who had said other GNU packages had dropped K&R without
> complaint.  I think I said eggert/meyering, which I assumed would be
> convincing, but I didn't hear more.

Actually, Jim Meyering and I were conservative, as we did it only
fairly recently.  GDB dropped K&R support in May, 1999.  They did it
gradually, by putting a prototyped function declaration in GDB 4.18
and seeing whether anyone would complain.  Nobody did.  So they
dropped K&R support entirely after that.

> [Is it worth me sending any more changes to gnulib?  Parts of changes
> not related to K&R never went in as far as I can tell.]

I will raise the priority of this.  I see three changes that you sent:

getloadavg.c.  I will check in that change
<http://mail.gnu.org/archive/html/bug-gnulib/2003-06/msg00023.html>
today.  Sorry for the delay.  I'll probably check in some other changes
after I check in the Emacs version, to merge with coreutils etc.

strftime.c.  I'll look into this soon.  It will take a bit more time.

regex.c/.h.  Here gnulib matches Emacs exactly, but the problem is
that there are two regex.c implementations.  We should merge with
glibc regex at some point, but that's a big task -- probably the
biggest single task in cleaning up the divergence.