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

[Andrew Innes <andrewi@gnu.org>]

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