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

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

[Dave Love]

[-- Attachment #1: Type: text/plain, Size: 494 bytes --]

Can anyone comment on issues below, arising from an attempt to merge
with the gnulib version of strftime?  It's specifically rms's change
which depends on __hpux rather than testing for sys/_mbstate_t.h, and
andrewi's changes involving USE_CRT_DLL and WINDOWSNT.  Jim's
suggestion about HAVE_TZNAME isn't relevant because that's actually
what HAVE_TZNAME means, and it turns out ms-w32.h defines it.  What
does USE_CRT_DLL mean, and does Windows always have the semantics of
it being defined?


[-- Attachment #2: Type: message/rfc822, Size: 3442 bytes --]

From: Jim Meyering <jim@meyering.net>
To: Dave Love <d.love@dl.ac.uk>
Cc: bug-gnulib@gnu.org
Subject: Re: [Bug-gnulib] strftime merge from Emacs
Date: Thu, 05 Jun 2003 09:03:43 +0200
Message-ID: <85el29ypio.fsf@pi.meyering.net>

Dave Love <d.love@dl.ac.uk> wrote:
> I merged these from Emacs (and pending changes thereto).  Is the
> copyright notice meant to be GPL rather than LGPL?

Thanks for all that work!

> 2003-06-04  Dave Love  <fx@gnu.org>
>
> 	[From Emacs]
>
> 	* strftime.c: Change some #if to #ifdef.

I've been trying to keep the gnulib version of strftime
more or less in sync with the one from glibc,
so would prefer that such cosmetic changes be made
in the primary source.

I think it's time to try to merge some of our
changes back into libc.  Once things stabilize here
maybe we can convince the libc folks to accept a few patches.

> 	[__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.

> 	(mbsinit): Define as no-op if not available.
> 	[!__P]: Use PROTOTYPES.

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?

Do any packages other than gcc and binutils cater to such old C compilers?

> 	[USE_CRT_DLL]: Remove unnecessary extern, which screws up
> 	dllimport attributes.

Could that `#if HAVE_TZNAME' block be replaced with this?
assuming you add the autoconf test, AC_CHECK_DECLS([tzname]), of course.

#if HAVE_DECL_TZNAME
extern char *tzname[];
#endif

> 	(my_strftime): Don't special-case Emacs.
> 	[WINDOWSNT]: Don't apply Solaris 2.5 work-around on Windows.

I haven't seen WINDOWSNT used before.
Here are some of the window-related macros I have seen:

  _WIN32 WIN32 __WIN32__ __MSDOS__ WINDOWS32

In any case, we try hard not to use system-dependent macros like that
and prefer to use the results of configure-time tests.  Is that
feasible here?

> 	(my_strftime) [STRFTIME_NO_POSIX2]: Handle %h when underlying
> 	strftime does not.

Although I see that emacs enables that code currently only via a
#define in `nt/config.nt', it looks like it might be useful for
other systems.  If it becomes an issue, I'm sure someone will write
an autoconf test.

> 	(emacs_strftimeu): Undef ut.
>
> Index: strftime.c
> ===================================================================
> RCS file: /cvsroot/gnulib/gnulib/lib/strftime.c,v
> retrieving revision 1.69


[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

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

[Jason Rumney]

Dave Love wrote:
> Can anyone comment on issues below, arising from an attempt to merge
> with the gnulib version of strftime?  It's specifically rms's change
> which depends on __hpux rather than testing for sys/_mbstate_t.h, and
> andrewi's changes involving USE_CRT_DLL and WINDOWSNT.  Jim's
> suggestion about HAVE_TZNAME isn't relevant because that's actually
> what HAVE_TZNAME means, and it turns out ms-w32.h defines it.  What
> does USE_CRT_DLL mean, and does Windows always have the semantics of
> it being defined?

USE_CRT_DLL indicates that the Windows system C runtime library is used
by Emacs. It is defined by the Makefile when compiling with gcc on
Windows, so I guess it means as opposed to glibc. Perhaps it is
implicitly defined when compiling with msvc, I am not sure, but looking
at the timing of when it was added, I think it is connected with the
addition of support for gcc on Windows. An alternative would be to
use configure tests to detect when tzname[] is not declared by <time.h>
or <sys/time.h>, and only declare it in that case.


WINDOWSNT is defined in the Emacs makefiles.

 >>	[WINDOWSNT]: Don't apply Solaris 2.5 work-around on Windows.
 >
 > In any case, we try hard not to use system-dependent macros like that
 > and prefer to use the results of configure-time tests.  Is that
 > feasible here?

It is probably better to detect the buggy Solaris 2.5 implementation
and only apply the work-around there. The conditional is too complex
as it is, and might be picking up other non-buggy implementations in
addition to WINDOWSNT (where it was noticed because it caused buggy
behaviour).

Full text of original below for Andrew's benefit:

> ------------------------------------------------------------------------
> 
> Subject:
> Re: [Bug-gnulib] strftime merge from Emacs
> From:
> Jim Meyering <jim@meyering.net>
> Date:
> Thu, 05 Jun 2003 09:03:43 +0200
> To:
> Dave Love <d.love@dl.ac.uk>
> 
> 
> Dave Love <d.love@dl.ac.uk> wrote:
> 
>>I merged these from Emacs (and pending changes thereto).  Is the
>>copyright notice meant to be GPL rather than LGPL?
> 
> 
> Thanks for all that work!
> 
> 
>>2003-06-04  Dave Love  <fx@gnu.org>
>>
>>	[From Emacs]
>>
>>	* strftime.c: Change some #if to #ifdef.
> 
> 
> I've been trying to keep the gnulib version of strftime
> more or less in sync with the one from glibc,
> so would prefer that such cosmetic changes be made
> in the primary source.
> 
> I think it's time to try to merge some of our
> changes back into libc.  Once things stabilize here
> maybe we can convince the libc folks to accept a few patches.
> 
> 
>>	[__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.
> 
> 
>>	(mbsinit): Define as no-op if not available.
>>	[!__P]: Use PROTOTYPES.
> 
> 
> 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?
> 
> Do any packages other than gcc and binutils cater to such old C compilers?
> 
> 
>>	[USE_CRT_DLL]: Remove unnecessary extern, which screws up
>>	dllimport attributes.
> 
> 
> Could that `#if HAVE_TZNAME' block be replaced with this?
> assuming you add the autoconf test, AC_CHECK_DECLS([tzname]), of course.
> 
> #if HAVE_DECL_TZNAME
> extern char *tzname[];
> #endif
> 
> 
>>	(my_strftime): Don't special-case Emacs.
>>	[WINDOWSNT]: Don't apply Solaris 2.5 work-around on Windows.
> 
> 
> I haven't seen WINDOWSNT used before.
> Here are some of the window-related macros I have seen:
> 
>   _WIN32 WIN32 __WIN32__ __MSDOS__ WINDOWS32
> 
> In any case, we try hard not to use system-dependent macros like that
> and prefer to use the results of configure-time tests.  Is that
> feasible here?
> 
> 
>>	(my_strftime) [STRFTIME_NO_POSIX2]: Handle %h when underlying
>>	strftime does not.
> 
> 
> Although I see that emacs enables that code currently only via a
> #define in `nt/config.nt', it looks like it might be useful for
> other systems.  If it becomes an issue, I'm sure someone will write
> an autoconf test.
> 
> 
>>	(emacs_strftimeu): Undef ut.
>>
>>Index: strftime.c
>>===================================================================
>>RCS file: /cvsroot/gnulib/gnulib/lib/strftime.c,v
>>retrieving revision 1.69
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: [Jim Meyering] Re: strftime merge from Emacs

[Andrew Innes]

On Fri, 06 Jun 2003 14:24:28 +0100, Jason Rumney <jasonr@gnu.org> said:
>Dave Love wrote:
>>Can anyone comment on issues below, arising from an attempt to merge
>>with the gnulib version of strftime?  It's specifically rms's change
>>which depends on __hpux rather than testing for sys/_mbstate_t.h, and
>>andrewi's changes involving USE_CRT_DLL and WINDOWSNT.  Jim's
>>suggestion about HAVE_TZNAME isn't relevant because that's actually
>>what HAVE_TZNAME means, and it turns out ms-w32.h defines it.  What
>>does USE_CRT_DLL mean, and does Windows always have the semantics of
>>it being defined?
>
>USE_CRT_DLL indicates that the Windows system C runtime library is used
>by Emacs. It is defined by the Makefile when compiling with gcc on
>Windows, so I guess it means as opposed to glibc. Perhaps it is
>implicitly defined when compiling with msvc, I am not sure, but looking
>at the timing of when it was added, I think it is connected with the
>addition of support for gcc on Windows. An alternative would be to
>use configure tests to detect when tzname[] is not declared by <time.h>
>or <sys/time.h>, and only declare it in that case.
>

Hi Jason,

You are correct, USE_CRT_DLL is only defined when Emacs is compiled for
Windows with GCC/Mingw - that is, compiled with GCC using the Mingw
headers and libraries, which in fact means using one of the "standard" C
libraries available on Windows (crtdll.dll or msvcrt.dll).

Slightly more background, if it matters:

When compiling with MSVC (originally the only compiler we supported for
Windows), the MS C library is (and always has been) statically linked,
which has made it possible to replace some of its functions and globals
with our own versions when necessary, but that is not possible when
using the DLL version of the Windows C library.  (GCC/Mingw only
supports compiling programs to use the DLL version of the C library.)

When adding support for using GCC/Mingw, to avoid breaking the MSVC
build with static libc, I invented USE_CRT_DLL.  It is still only used
for GCC/Mingw although it should work with MSVC.

Neither of these builds of Emacs for Windows uses glibc.  The pure
Cygwin build I guess may do, but that isn't something I've ever worked
on so I can't speak for it.

>WINDOWSNT is defined in the Emacs makefiles.
>
>>>[WINDOWSNT]: Don't apply Solaris 2.5 work-around on Windows.
>>
>>In any case, we try hard not to use system-dependent macros like that
>>and prefer to use the results of configure-time tests.  Is that
>>feasible here?
>
>It is probably better to detect the buggy Solaris 2.5 implementation
>and only apply the work-around there. The conditional is too complex
>as it is, and might be picking up other non-buggy implementations in
>addition to WINDOWSNT (where it was noticed because it caused buggy
>behaviour).

I think I would support this suggestion.  I only vaguely remember trying
to work out a way to get strftime.c to compile and link using GCC/Mingw,
so I can't remember what other solutions I tried before settling on
using WINDOWSNT as a conditional, though I do remember struggling with
it for a while.  If the piece of code is only a work-around for one
particular platform bug, it would seem cleaner to detect just the buggy
platform instead.

(In case it isn't clear, WINDOWSNT is another #define that is private to
the Windows port of Emacs, as is USE_CRT_DLL.)

AndrewI

>Full text of original below for Andrew's benefit:
>
>>------------------------------------------------------------------------
>>
>>Subject:
>>Re: [Bug-gnulib] strftime merge from Emacs
>>From:
>>Jim Meyering <jim@meyering.net>
>>Date:
>>Thu, 05 Jun 2003 09:03:43 +0200
>>To:
>>Dave Love <d.love@dl.ac.uk>
>>
>>
>>Dave Love <d.love@dl.ac.uk> wrote:
>>
>>>I merged these from Emacs (and pending changes thereto).  Is the
>>>copyright notice meant to be GPL rather than LGPL?
>>
>>
>>Thanks for all that work!
>>
>>
>>>2003-06-04  Dave Love  <fx@gnu.org>
>>>
>>>[From Emacs]
>>>
>>>* strftime.c: Change some #if to #ifdef.
>>
>>
>>I've been trying to keep the gnulib version of strftime
>>more or less in sync with the one from glibc,
>>so would prefer that such cosmetic changes be made
>>in the primary source.
>>
>>I think it's time to try to merge some of our
>>changes back into libc.  Once things stabilize here
>>maybe we can convince the libc folks to accept a few patches.
>>
>>
>>>[__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.
>>
>>
>>>(mbsinit): Define as no-op if not available.
>>>[!__P]: Use PROTOTYPES.
>>
>>
>>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?
>>
>>Do any packages other than gcc and binutils cater to such old C compilers?
>>
>>
>>>[USE_CRT_DLL]: Remove unnecessary extern, which screws up
>>>dllimport attributes.
>>
>>
>>Could that `#if HAVE_TZNAME' block be replaced with this?
>>assuming you add the autoconf test, AC_CHECK_DECLS([tzname]), of course.
>>
>>#if HAVE_DECL_TZNAME
>>extern char *tzname[];
>>#endif
>>
>>
>>>(my_strftime): Don't special-case Emacs.
>>>[WINDOWSNT]: Don't apply Solaris 2.5 work-around on Windows.
>>
>>
>>I haven't seen WINDOWSNT used before.
>>Here are some of the window-related macros I have seen:
>>
>>_WIN32 WIN32 __WIN32__ __MSDOS__ WINDOWS32
>>
>>In any case, we try hard not to use system-dependent macros like that
>>and prefer to use the results of configure-time tests.  Is that
>>feasible here?
>>
>>
>>>(my_strftime) [STRFTIME_NO_POSIX2]: Handle %h when underlying
>>>strftime does not.
>>
>>
>>Although I see that emacs enables that code currently only via a
>>#define in `nt/config.nt', it looks like it might be useful for
>>other systems.  If it becomes an issue, I'm sure someone will write
>>an autoconf test.
>>
>>
>>>(emacs_strftimeu): Undef ut.
>>>
>>>Index: strftime.c
>>>===================================================================
>>>RCS file: /cvsroot/gnulib/gnulib/lib/strftime.c,v
>>>retrieving revision 1.69
>>
>>
>>
>>------------------------------------------------------------------------
>>
>>_______________________________________________
>>Emacs-devel mailing list
>>Emacs-devel@gnu.org
>>http://mail.gnu.org/mailman/listinfo/emacs-devel
>
>
>

Re: [Jim Meyering] Re: strftime merge from Emacs

[Dave Love]

Andrew Innes <andrewi@gnu.org> writes:

> You are correct, USE_CRT_DLL is only defined when Emacs is compiled for
> Windows with GCC/Mingw - that is, compiled with GCC using the Mingw
> headers and libraries, which in fact means using one of the "standard" C
> libraries available on Windows (crtdll.dll or msvcrt.dll).

The question concerns this fragment:

#if HAVE_TZNAME
#ifndef USE_CRT_DLL
extern char *tzname[];
#endif
#endif

Should the Windows port define HAVE_TZNAME dependent on USE_CRT_DLL,
not unconditionally?

Re: [Jim Meyering] Re: strftime merge from Emacs

[Dave Love]

Jason Rumney <jasonr@gnu.org> writes:

> An alternative would be to
> use configure tests to detect when tzname[] is not declared by <time.h>
> or <sys/time.h>, and only declare it in that case.

As I said, there already is such a test, and the Windows port defines
HAVE_TZNAME (which is one of the things the autoconf test does).
Should it not do so?

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

[Jason Rumney]

Dave Love <d.love@dl.ac.uk> writes:

> Jason Rumney <jasonr@gnu.org> writes:
> 
> > An alternative would be to
> > use configure tests to detect when tzname[] is not declared by <time.h>
> > or <sys/time.h>, and only declare it in that case.
> 
> As I said, there already is such a test, and the Windows port defines
> HAVE_TZNAME (which is one of the things the autoconf test does).
> Should it not do so?

If HAVE_TZNAME means what I think it does, then the Windows port
should define it.  The problem in this case is that the declaration
in strftime.c conflicts with the one in <time.h> when built with
MingW32, because of the fact that tzname[] actually resides within a
shared library, so its method of dereferencing is not normal.

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

[Bruno Haible]

Jason Rumney wrote:
> If HAVE_TZNAME means what I think it does, then the Windows port
> should define it.  The problem in this case is that the declaration
> in strftime.c conflicts with the one in <time.h> when built with
> MingW32, because of the fact that tzname[] actually resides within a
> shared library, so its method of dereferencing is not normal.

Would it work to add
    #define tzname (*tzname)
to the config.h for mingw in this case?

Bruno

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

[Jason Rumney]

Bruno Haible wrote:
> Jason Rumney wrote:
> 
>>If HAVE_TZNAME means what I think it does, then the Windows port
>>should define it.  The problem in this case is that the declaration
>>in strftime.c conflicts with the one in <time.h> when built with
>>MingW32, because of the fact that tzname[] actually resides within a
>>shared library, so its method of dereferencing is not normal.
> 
> 
> Would it work to add
>     #define tzname (*tzname)
> to the config.h for mingw in this case?

No, in the system headers, tzname is defined as

__MINGW_IMPORT char 	*tzname[2];

The conflict is with the __MINGW_IMPORT, which is missing in the
extern declaration in strftime.h


I wonder why you need to redeclare tzname[] there, do header files not
already declare it on platforms where HAVE_TZNAME is defined?

Re: [Jim Meyering] Re: strftime merge from Emacs

[Paul Eggert]

Jason Rumney <jasonr@gnu.org> writes:

> I wonder why you need to redeclare tzname[] there, do header files not
> already declare it on platforms where HAVE_TZNAME is defined?

Yes, depending on compilation options.  For example, I get the
following symptomps on both Debian GNU/Linux 3.0r1 and on Solaris 8:

   $ cat t.c
   #include <time.h>
   int main (void) { return !tzname; }
   $ gcc -c t.c
   $ gcc -c -ansi t.c
   t.c: In function `main':
   t.c:2: `tzname' undeclared (first use in this function)
   t.c:2: (Each undeclared identifier is reported only once
   t.c:2: for each function it appears in.)

This is because the C standard does not allow <time.h> to declare
tzname; a strictly conforming C program can declare its own variable
called 'tzname' with entirely different semantics.

Perhaps AC_STRUCT_TIMEZONE should also check whether tzname is
declared, and if so, define HAVE_DECL_TZNAME.  Then we could adjust
the code as follows:

#if HAVE_TZNAME && !HAVE_DECL_TZNAME && !defined tzname
extern char *tzname[];
#endif

Re: [Jim Meyering] Re: strftime merge from Emacs

[Eli Zaretskii]

> From: Paul Eggert <eggert@CS.UCLA.EDU>
> Date: 11 Jun 2003 10:29:34 -0700
> 
> > I wonder why you need to redeclare tzname[] there, do header files not
> > already declare it on platforms where HAVE_TZNAME is defined?
> 
> Yes, depending on compilation options.  For example, I get the
> following symptomps on both Debian GNU/Linux 3.0r1 and on Solaris 8:
> 
>    $ cat t.c
>    #include <time.h>
>    int main (void) { return !tzname; }
>    $ gcc -c t.c
>    $ gcc -c -ansi t.c
>    t.c: In function `main':
>    t.c:2: `tzname' undeclared (first use in this function)
>    t.c:2: (Each undeclared identifier is reported only once
>    t.c:2: for each function it appears in.)

But we don't use -ansi in Emacs, so this particular problem is not
really relevant, is it?  (I don't know whether gnulib can be built
with -ansi, but I sincerely doubt it.)

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

[Paul Eggert]

"Eli Zaretskii" <eliz@elta.co.il> writes:

> we don't use -ansi in Emacs, so this particular problem is not
> really relevant, is it?  (I don't know whether gnulib can be built
> with -ansi, but I sincerely doubt it.)

Tools that use gnulib are regularly built by all sorts of picky C
compilers.  That is why all gnulib modules should build even with gcc
-ansi -pedantic, even if GNU Emacs doesn't need this feature.

Installers who insist on compiling applications with picky compilers
may suffer a bit in performance -- or, in a pinch, they might even go
without some behavior extensions -- but the application should still
run and should still be useful.

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

[Bruno Haible]

Paul Eggert wrote:
> Perhaps AC_STRUCT_TIMEZONE should also check whether tzname is
> declared, and if so, define HAVE_DECL_TZNAME.

I agree, "extern char *tzname[];" is a common idiom, and now that
we know that it needs conditionalization on mingw, the right place
for a fix is to change AC_STRUCT_TIMEZONE and its documentation.

Bruno

Re: [Jim Meyering] Re: strftime merge from Emacs

[Dave Love]

Jason Rumney <jasonr@gnu.org> writes:

> If HAVE_TZNAME means what I think it does, then the Windows port
> should define it.

I've just checked, and it means that you can link a main with the
body:

 atoi(*tzname);

and preamble:

 #include <time.h>
 #ifndef tzname /* For SGI.  */
 extern char *tzname[]; /* RS6000 and others reject char **tzname.  */
 #endif

> The problem in this case is that the declaration
> in strftime.c conflicts with the one in <time.h> when built with
> MingW32, because of the fact that tzname[] actually resides within a
> shared library, so its method of dereferencing is not normal.

I now realize I don't understand why the declaration is there at all
and why the test is written as it is, though doubtless there's a good
reason.  I'd have expected the test just to be whether tzname was
usable as an array after including time.h in the POSIX namespace.
Then strftime would only need to define _POSIX_C_SOURCE and include
the header.

Does anyone know what's the problem defining the macros for POSIX (and
other) features?  (Emacs does that when necessary, or at least where
necessary on the platforms I've had to sort out.)

Re: [Jim Meyering] Re: strftime merge from Emacs

[Paul Eggert]

Dave Love <d.love@dl.ac.uk> writes:

> Then strftime would only need to define _POSIX_C_SOURCE and include
> the header.
> 
> Does anyone know what's the problem defining the macros for POSIX (and
> other) features?

I've found that it's better to avoid those feature-test macros if
possible, as they tend to explore rarely-used and buggy corners of
include files, and they tend to disable other useful features.  My
experience is that it is sometimes necessary to use them on some
platforms, but it's better not to use them by default.

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

[Dave Love]

Paul Eggert <eggert@CS.UCLA.EDU> writes:

> I've found that it's better to avoid those feature-test macros if
> possible, as they tend to explore rarely-used and buggy corners of
> include files, and they tend to disable other useful features.  My
> experience is that it is sometimes necessary to use them on some
> platforms, but it's better not to use them by default.

Surely it's incorrect not to use them if you want to use the features?
It's certainly necessary to enable feature-test macros on various
systems, including GNU, for Emacs.  Even where the default compiler
options don't make it necessary (e.g. Irix), if you change them to
something like `-ansi', you typically lose.  I've seen this actually
happen on systems like Irix and Tru64 where you can change the default
options with a configuration file or environment variable.

I'm thinking of things like _XOPEN_SOURCE, which won't disable much.

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

[Paul Eggert]

Dave Love <d.love@dl.ac.uk> writes:

> Surely it's incorrect not to use them if you want to use the features?

The usual tradition is that hosts enable all extensions unless you
specifically ask that extensions be disabled.  Some hosts don't follow
this tradition: instead, they enable only a standard subset by
default, and you have to define some nonstandard feature-test macro
like __EXTENSIONS__ or _GNU_SOURCE in order to enable all extensions.
For such systems, it's obviously OK to define _GNU_SOURCE etc., as
that's the way to say "I want all extensions", which is the normal
thing that Autoconfed packages want to say.

However, I've found that it's usually a mistake to play with
feature-test macros any more than that.  In other words, it's usually
a mistake to futz with more-specific feature-test macros like
_XOPEN_SOURCE and _POSIX_SOURCE.  This is for two reasons.  First,
these macros generally disable some extensions, and that's not what
Autoconfized packages usually want.  Second, these macros are rarely
used, so their use often triggers bugs in headers.


> I'm thinking of things like _XOPEN_SOURCE, which won't disable much.

And I'm also thinking of things like _XOPEN_SOURCE.  For example,
AC_SYS_LARGEFILE used to "#define _XOPEN_SOURCE 500" when it detected
a certain bug in glibc 2.1.3, to work around that bug.  (The bug was
that glibc did not declare fseeko unless you defined _XOPEN_SOURCE.)
But this caused far too many other problems in practice: it disabled
many other useful extensions.  When AC_SYS_LARGEFILE stopped mucking
with _XOPEN_SOURCE, the problems largely went away, and this was a win
overall.

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

[Stephen J. Turnbull]

>>>>> "Paul" == Paul Eggert <eggert@CS.UCLA.EDU> writes:

    Paul> Dave Love <d.love@dl.ac.uk> writes:

    >> Surely it's incorrect not to use them if you want to use the
    >> features?

    Paul> However, I've found that it's usually a mistake to play with
    Paul> feature-test macros any more than that.

FWIW, XEmacs does use the feature-test macros.  config.h sets (or not)
all of _POSIX_C_SOURCE, _XOPEN_SOURCE, _XOPEN_SOURCE_EXTENDED,
_ALL_SOURCE (for AIX), _GNU_SOURCE (for glibc), and __EXTENSIONS__
(for Solaris), and if you've got X11, it also uses _POSIX_SOURCE,
_BSD_SOURCE, and _SVID_SOURCE.

That's a lot of macros!  Martin Buchholz spent many hours studying
standards and reviewing code to keep up with all this stuff, and make
sure the preprocessor conditionals checked the correct feature macros
etc.  So I guess our experience mostly supports Paul's position.  You
could ask Martin <martin@xemacs.org>.

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.

Re: [Jim Meyering] Re: strftime merge from Emacs

[Richard Stallman]

    > 	[__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.

    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?

    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: strftime merge from Emacs

[Jim Meyering]

Richard Stallman <rms@gnu.org> 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

[Eli Zaretskii]

> From: Jim Meyering <jim@meyering.net>
> Date: Sat, 07 Jun 2003 17:28:13 +0200
> 
> >     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.

I believe WINDOWS32 is a better name.  IIRC, GNU Make uses it.

(WINDOWSNT is something that emerged in Emacs historically; it might
not make much sense elsewehere.)

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

[Bruno Haible]

Eli Zaretskii wrote:
> I believe WINDOWS32 is a better name.  IIRC, GNU Make uses it.

I believe it's a poor name because Microsoft pretends to have the trademark
on "Windows" in the US and is sueing other companies for this reason.

Therefore my preference is to use the compiler-defined macros
(defined _WIN32 || defined __WIN32__), for which one cannot be sued,
or a neutral macro like 'WOE32' (just as neutral as 'MSDOG' was in the
past :-)).

Bruno  

Re: [Jim Meyering] Re: strftime merge from Emacs

[Eli Zaretskii]

> From: Bruno Haible <haible@ilog.fr>
> Date: Sat, 7 Jun 2003 19:03:45 +0200
> 
> Eli Zaretskii wrote:
> > I believe WINDOWS32 is a better name.  IIRC, GNU Make uses it.
> 
> I believe it's a poor name because Microsoft pretends to have the trademark
> on "Windows" in the US and is sueing other companies for this reason.

I know about several GNU packages that use WINDOWS32, and never heard
of any of them being sued.

> Therefore my preference is to use the compiler-defined macros
> (defined _WIN32 || defined __WIN32__), for which one cannot be sued,

As already mentioned in this thread, it is a policy of the GNU project
to avoid implying that Windows is ``a win''.  So I doubt if any of
these will be acceptable.

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

[Richard Stallman]

    I believe it's a poor name because Microsoft pretends to have the trademark
    on "Windows" in the US and is sueing other companies for this reason.

Trademark law has nothing to do with symbol names used inside a program.
You can talk about "Microsoft Windows" however you like in a book;
you don't need permission.

    Therefore my preference is to use the compiler-defined macros
    (defined _WIN32 || defined __WIN32__), for which one cannot be sued,

In hacker terminology, calling something a "win" is a form of praise.
If you wish to praise Microsoft Windows, you're free to do so; but if you
don't, then you might want to think twice about using the term "win32".
In any case, don't use it in GNU software.

Avoiding WIN* macros in GNU code [was Re: [Jim Meyering] Re: [Bug-gnulib] strftime merge from Emacs]

[Derek Robert Price]

Richard Stallman wrote:

>    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?
>  
>

CVS was using it.  I just changed that, aside from a reference in 
lib/system.h to set WOE32 when it found WIN32 defined.

I did notice that gzip/zlib appears to be switching on WIN32 
extensively, at least as of 1.1.4.  I've cc'd the zlib-devel mailing list.

There was also one switch on _WIN32 in the version of GNU diff that CVS 
uses, but we're several releases behind the latest GNU diff release.

Derek

-- 
                *8^)

Email: derek@ximbiot.com

Get CVS support at <http://ximbiot.com>!

Re: [Zlib-devel] Avoiding WIN* macros in GNU code [was Re: [Jim Meyering] Re: [Bug-gnulib] strftime merge from Emacs]

[Cosmin Truta]

On Mon, 9 Jun 2003, Derek Robert Price wrote:

> Richard Stallman wrote:
>
> >    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?

The abbreviation is not WIN, but it is WIN32. I think WINDOWSNT is a
misnomer, because Windows 95/98/ME is not at all NT, and the newer
versions are not named "NT" anymore (even if they are based on the NT
kernel). The term "Win32" is used consistently in all versions, and it
really means "32-bit Windows", whether NT or not.


> CVS was using it.  I just changed that, aside from a reference in
> lib/system.h to set WOE32 when it found WIN32 defined.

I cannot recall a particular piece of software, but I saw lots of
WIN32 and _WIN32 symbols, and I used to read plenty of GNU source code.
I admit this was some time ago.


> I did notice that gzip/zlib appears to be switching on WIN32
> extensively, at least as of 1.1.4.  I've cc'd the zlib-devel mailing list.

The Win32 support appeared before 1.1.4, but it doesn't affect the
functionality on other platforms. We try hard to keep it this way ;)


By the way, what is the problem with using WIN32? Is there any danger to
clash with something else? The point is that WIN32 is something easy to
rely on:

  #if !defined(WIN32) && (defined(_WIN32) || defined(__WIN32__))
  #define WIN32
  #endif

Plenty of software use this or something related, and it's pretty much
failproof. Why add and maintain yet another nonstandard symbol?


Best regards,
Cosmin

Re: [Zlib-devel] Avoiding WIN* macros in GNU code [was Re: [Jim Meyering] Re: [Bug-gnulib] strftime merge from Emacs]

[Miles Bader]

Cosmin Truta <cosmin@cs.toronto.edu> writes:
> By the way, what is the problem with using WIN32?

Because it's a misnomer (and a particularly annoying one).

-Miles
-- 
Run away!  Run away!

Re: [Zlib-devel] Avoiding WIN* macros in GNU code [was Re: [Jim Meyering] Re: [Bug-gnulib] strftime merge from Emacs]

[Richard Stallman]

    The abbreviation is not WIN, but it is WIN32.

Same difference.

    By the way, what is the problem with using WIN32?

It includes the word "win", and we don't want to call Microsoft
Windows a win.

Re: [Zlib-devel] Avoiding WIN* macros in GNU code

[Cosmin Truta]

On Thu, 12 Jun 2003, Richard Stallman wrote:

>     The abbreviation is not WIN, but it is WIN32.
>
> Same difference.
>
>     By the way, what is the problem with using WIN32?
>
> It includes the word "win", and we don't want to call Microsoft
> Windows a win.

I understand. Should we do the same in zlib?
Is there an official GNU coding standard that states this?

There is still a very peculiar problem with WINDOWSNT: it indicates a
version of MS Windows that is based on an NT kernel, as opposed to a
version based on a Win9x kernel. The official _WINNT symbol indicates
exactly this. Software rely on it when calling Windows NT-specific
services.

The confusion created by WINDOWSNT is similar to one created by a
hypothetical REDHAT_LINUX symbol that would mean "GNU/Linux in general".

So may I suggest something like WINDOWS32 or MSWINDOWS32 instead?
I believe no other windowing system uses WINDOWS or WINDOWS32...

I also wish to point out that the introduction of a yet another new
macro doesn't help. The old ones must still be maintained, because
compilers (including gcc/Win32) preset them, and users rely on them.
Like it or not ... those macros are official, and well-known among
Windows programmers.


(After all, is this "Win32" naming thing one of Microsoft's strategic
moves? :)


Best regards,
Cosmin

Re: [Zlib-devel] Avoiding WIN* macros in GNU code

[Jason Rumney]

Cosmin Truta wrote:

> There is still a very peculiar problem with WINDOWSNT:

The usage of WINDOWSNT in Emacs is historical, and is due to the fact
that the original port of Emacs to Windows NT predates the release of
Windows 95. Your suggestion to use WINDOWS32 or MSWINDOWS32 is a good
one for projects looking to adopt a convention now.

Re: [Zlib-devel] Avoiding WIN* macros in GNU code

[Richard Stallman]

    > It includes the word "win", and we don't want to call Microsoft
    > Windows a win.

    I understand. Should we do the same in zlib?

I think so.

    Is there an official GNU coding standard that states this?

It wasn't part of the coding standards before.  I am adding it now.
This often happens--that we have a policy but it takes some 
time before I realize it ought to be in the coding standards.

    There is still a very peculiar problem with WINDOWSNT: it indicates a
    version of MS Windows that is based on an NT kernel, as opposed to a
    version based on a Win9x kernel.

I agree that the symbol WINDOWSNT may not be the best one to use.  If
the idea is to mean any 32-bit version of Windows, WINDOWS32 is better.

    (After all, is this "Win32" naming thing one of Microsoft's strategic
    moves? :)

I would not call it a strategic move, but I think it is a PR campaign.
To say "We will win, you know it" is a common tactic of psychological
combat.

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

[Dave Love]

Richard Stallman <rms@gnu.org> writes:

>     > 	[__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's the proposal.

> That will work provided there is no case
> where that file exists but including it is harmful.

The question is really whether there is any reason to think it might
be harmful, i.e. why wasn't it done like that originally?  If no-one
knows, it seems best just to do it, as it seems unlikely to cause
grief.

>     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?

Gcc actually defines them.

>     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.

This should be just a matter of defining the relevant macros in or via
config.nt.  Similarly with MacOS.

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

[Richard Stallman]

    > That will work provided there is no case
    > where that file exists but including it is harmful.

    The question is really whether there is any reason to think it might
    be harmful, i.e. why wasn't it done like that originally?  If no-one
    knows, it seems best just to do it, as it seems unlikely to cause
    grief.

I would suspect the conditional was written before there was Autoconf,
and that there was no technical reason not to use Autoconf if it had
existed.

    >       _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?

    Gcc actually defines them.

Do other compilers for Windows define them too?  If so, then GCC
should define them also; it is a technical need.  If not, we should
rename them.

Re: [Jim Meyering] Re: strftime merge from Emacs

[Benjamin Riefenstahl]

Hi Richard,


Richard Stallman <rms@gnu.org> writes:
>     >       _WIN32 WIN32 __WIN32__ __MSDOS__ WINDOWS32
>
> Do other compilers for Windows define them too?

I have seen _WIN32, WIN32, __WIN32__ and __MSDOS__ defined by versions
of Borland and/or MSC.  GCC (3.2) defines _WIN32, WIN32, __WIN32__ in
the Mingw version, but not in Cygwin.

WINDOWS32 seems to be a user define, I do not remember that I have
seen that predefined by any compiler.


benny

Re: [Jim Meyering] Re: strftime merge from Emacs

[Jason Rumney]

Richard Stallman wrote:

>     >       _WIN32 WIN32 __WIN32__ __MSDOS__ WINDOWS32
>     >
> 
>     Gcc actually defines them.
> 
> Do other compilers for Windows define them too?

Most (maybe all) Windows compilers define __WIN32__. I don't think
any of the others are widespread though (maybe __MSDOS__ on MS-DOS).

Re: [Jim Meyering] Re: strftime merge from Emacs

[Eli Zaretskii]

> Date: Thu, 12 Jun 2003 18:59:03 +0100
> From: Jason Rumney <jasonr@gnu.org>
> 
> Most (maybe all) Windows compilers define __WIN32__. I don't think
> any of the others are widespread though (maybe __MSDOS__ on MS-DOS).

The DJGPP port of GCC defines __MSDOS__.

Re: [Jim Meyering] Re: strftime merge from Emacs

[Richard Stallman]

    >     >       _WIN32 WIN32 __WIN32__ __MSDOS__ WINDOWS32
    >     >
    > 
    >     Gcc actually defines them.
    > 
    > Do other compilers for Windows define them too?

    Most (maybe all) Windows compilers define __WIN32__.

I figured it was something like that.  It is necessary for GCC to
define the symbol that other compilers define; the other variants are
present because GCC automatically defines all those variants.

Re: [Jim Meyering] Re: strftime merge from Emacs

[Dave Love]

Richard Stallman <rms@gnu.org> writes:

> I would suspect the conditional was written before there was Autoconf,
> and that there was no technical reason not to use Autoconf if it had
> existed.

No, it's recent.  I'll change the test sometime.