emacs-devel
[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: Jason Rumney
Subject: Re: [Jim Meyering] Re: [Bug-gnulib] strftime merge from Emacs
Date: Fri, 06 Jun 2003 14:24:28 +0100
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210

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 <address@hidden>
Date:
Thu, 05 Jun 2003 09:03:43 +0200
To:
Dave Love <address@hidden>


Dave Love <address@hidden> 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  <address@hidden>

        [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
address@hidden
http://mail.gnu.org/mailman/listinfo/emacs-devel






reply via email to

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