bug-gnulib
[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: Dave Love
Subject: Re: [Jim Meyering] Re: [Bug-gnulib] strftime merge from Emacs
Date: Thu, 12 Jun 2003 23:42:40 +0100
User-agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.2 (gnu/linux)

Jason Rumney <address@hidden> 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.)




reply via email to

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