Re: [Bug-gnulib] strftime merge from Emacs

[Jim Meyering]

Dave Love <address@hidden> wrote:
> 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.)

In the packages I've been maintaining, I've preferred (and used) the
`#if HAVE_WHATEVER' syntax for many years.  I guess that just shows
how many people use traditional cpp.

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

Same here.
Do you know what the motivation was for that change?
It'd be good to see if there's another way to solve the problem.

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

It'd be great if you would do that!

> However, that change is actually for compilers that _do_ support
> prototypes but don't define __STDC__ by default.  Then if you're

Then configure can select the options necessary to enable prototypes?
If it doesn't, it should be fixed.

> 64-bit big-endian, you lose.  I think this bit me on Irix.

I've seen prototype-related trouble with such systems, too,
but none since I removed the offending conditionals,
leaving unconditional prototypes.

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

Is src/s/ms-w32.h the windows config file?
It's defined there, now:

  src/s/ms-w32.h:246:#define HAVE_TZNAME 1

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

Here, I think we can DTRT :-)
At worst, (assuming this is solaris-specific) change this code
to be used only on __sun__ systems.
At best, someone will write an autoconf-run-test to detect the
real problem.  Does anyone have details of how tzset misbehaves?

#if !defined _LIBC && HAVE_TZNAME && HAVE_TZSET
  /* Solaris 2.5 tzset sometimes modifies the storage returned by localtime.
     Work around this bug by copying *tp before it might be munged.  */


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

Sure. Thanks!