emacs-devel
[Top][All Lists]
Advanced

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

Re: [Jim Meyering] Re: [Bug-gnulib] strftime merge from Emacs


From: Jim Meyering
Subject: Re: [Jim Meyering] Re: [Bug-gnulib] strftime merge from Emacs
Date: Sat, 07 Jun 2003 17:28:13 +0200

Richard Stallman <address@hidden> wrote:
>     >         [__hpux]: Include sys/_mbstate_t.h.
>
>     Using a macro like __hpux should be done only as a last resort.
>     I hope there is a better way.
>
> One idea is to test using Autoconf for the existence of such a file
> and include it if it exists.  That will work provided there is no case
> where that file exists but including it is harmful.
>
>     Does emacs still cater to compilers that don't support prototypes?
>     I've been removing k&r support (PROTOTYPES, __P, etc.) from the coreutils
>     for years without complaint.  As far as emacs is concerned, is it possible
>     to remove such support from this file altogether?
>
> To remove it from strftime is tantamount to abandoning it in Emacs as
> a whole.  I think we should be very cautious about that.

Caution is fine.
However, I'm convinced that requiring a C89-compliant compiler
will not bother anyone these days, and as such, I do not hesitate
to remove support for K&R compilers anymore.

>     I haven't seen WINDOWSNT used before.
>     Here are some of the window-related macros I have seen:
>
>       _WIN32 WIN32 __WIN32__ __MSDOS__ WINDOWS32
>
> WINDOWSNT is what Emacs uses.  It is a GNU convention that we do not
> use the abbreviation "WIN" to refer to Windows.  Are those names
> used in any GNU packages?

Yes.  I found those uses in gnulib and the coreutils.
BTW, is WINDOWSNT an appropriate name for such a macro?
I've heard that some of the modules using those macros may be
compiled on non-Windows/NT systems.

In any case, I try very hard to avoid the use of such macros,
and believe I know how to eliminate cleanly the one in emacs'
src/strftime.c.

>     In any case, we try hard not to use system-dependent macros like that
>     and prefer to use the results of configure-time tests.
>
> That is preferable, but with a system as different from GNU as Windows is,
> code for a specific system will tend to be needed often.




reply via email to

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