[Top][All Lists]
[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.
- Re: [Jim Meyering] Re: [Bug-gnulib] strftime merge from Emacs, (continued)
- Re: [Jim Meyering] Re: [Bug-gnulib] strftime merge from Emacs, Bruno Haible, 2003/06/11
- Re: [Jim Meyering] Re: [Bug-gnulib] strftime merge from Emacs, Dave Love, 2003/06/12
- Re: [Jim Meyering] Re: [Bug-gnulib] strftime merge from Emacs, Paul Eggert, 2003/06/13
- Re: [Jim Meyering] Re: [Bug-gnulib] strftime merge from Emacs, Dave Love, 2003/06/16
- Re: [Jim Meyering] Re: [Bug-gnulib] strftime merge from Emacs, Paul Eggert, 2003/06/17
- Re: [Jim Meyering] Re: [Bug-gnulib] strftime merge from Emacs, Stephen J. Turnbull, 2003/06/17
Re: [Jim Meyering] Re: [Bug-gnulib] strftime merge from Emacs, Richard Stallman, 2003/06/07
- Re: [Jim Meyering] Re: [Bug-gnulib] strftime merge from Emacs,
Jim Meyering <=
Avoiding WIN* macros in GNU code [was Re: [Jim Meyering] Re: [Bug-gnulib] strftime merge from Emacs], Derek Robert Price, 2003/06/09
- Re: [Zlib-devel] Avoiding WIN* macros in GNU code [was Re: [Jim Meyering] Re: [Bug-gnulib] strftime merge from Emacs], Cosmin Truta, 2003/06/12
- Re: [Zlib-devel] Avoiding WIN* macros in GNU code [was Re: [Jim Meyering] Re: [Bug-gnulib] strftime merge from Emacs], Miles Bader, 2003/06/12
- Re: [Zlib-devel] Avoiding WIN* macros in GNU code [was Re: [Jim Meyering] Re: [Bug-gnulib] strftime merge from Emacs], Richard Stallman, 2003/06/12
- Re: [Zlib-devel] Avoiding WIN* macros in GNU code, Cosmin Truta, 2003/06/12
- Re: [Zlib-devel] Avoiding WIN* macros in GNU code, Jason Rumney, 2003/06/13