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

[Jason Rumney <jasonr@gnu.org>]

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