bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-gnulib] strftime merge from Emacs


From: Dave Love
Subject: Re: [Bug-gnulib] strftime merge from Emacs
Date: Thu, 05 Jun 2003 16:58:35 +0100
User-agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.2 (gnu/linux)

Jim Meyering <address@hidden> writes:

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

It's not cosmetic with a traditional cpp, though.  Also as far as I
know, #ifdef is what you're supposed to use with autoconf macros.  (I
was going to merge real cosmetics like whitespace diffs the other
way.)

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

Sure.  I'd have thought testing for sys/_mbstate_t.h would have been
sufficient.  rms made the change, and I don't know anything about
HPUX.

>>      (mbsinit): Define as no-op if not available.
>>      [!__P]: Use PROTOTYPES.
>
> Does emacs still cater to compilers that don't support prototypes?

Yes, but I'm not convinced it's worthwhile now.  I could lobby rms on
the basis that other packages have dropped it.

However, that change is actually for compilers that _do_ support
prototypes but don't define __STDC__ by default.  Then if you're
64-bit big-endian, you lose.  I think this bit me on Irix.

> As far as emacs is concerned, is it possible to remove such support
> from this file altogether?

Not at present, as I understand it.

> 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

Presumably not.  HAVE_TZNAME is the check for that declaration (via
AC_STRUCT_TIMEZONE).  Since the Doze config file undefs HAVE_TZNAME,
and I think that's the only thing that defines USE_CRT_DLL, I don't
understand it.  It was done by address@hidden, but I don't think he's
active these days.

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

Sure.  I think I understand the philosophy OK, and I don't necessarily
think config stuff in Emacs is right!  Several of us have made efforts
to have it DTRT with limited success :-(.  I'm one of the few people
who even test builds on proprietary systems as far as I can tell, and
I've had a hard time with lossage from running cpp on makefiles &c.

> Is that feasible here?

WINDOWSNT seems to be what Emacs uses consistently to define the
system type, maybe because of objections to `WIN' in that context.
However, since HAVE_TZNAME is undef'ed on Windows, I don't understand
that change either.

Should I just forward your mail to an Emacs list for possible answers?




reply via email to

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