Re: Bug in format-time-string in emacs 21.1?

Re: Bug in format-time-string in emacs 21.1?

[Jason Rumney]

Pavel@Janik.cz (Pavel Janík) writes:

>    From: Eli Zaretskii <eliz@is.elta.co.il>
>    Date: Tue, 12 Mar 2002 07:59:31 +0200 (IST)
> 
>    > > I think I've found a bug in the format-time-string function. In the 
>    > > documentation it says that the construct %h gives the abbreviated month 
>    > > name. I doesn't seem to work with 21.1. The %b construct still works.
>    > 
>    > I think this is a known problem with the MS-Windows time routines: they 
> 
> We should mention it in PROBLEMS then. Jason?

It turns out that %h is marked in the source code as a POSIX.2
extension, along with quite a few other format specifiers (which are
also not supported on Windows).

Rather than putting a note in PROBLEMS specific to %h on Windows, it
might be better to modify the doc-string for format-time-string, to
make it clear which specifiers are guaranteed to work, and which are
POSIX.2 or GNU extensions, and will only work on plaforms that
support them.

Alternatively, we could introduce more conditional blocks to
strftime.c to do something sensible with the POSIX.2 extensions on
platforms that only support POSIX.1 formats.  I think most of them
could be handled without too much effort.


-- 
Jason Rumney


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Bug in format-time-string in emacs 21.1?

[Paul Eggert]

> From: Jason Rumney <jasonr@gnu.org>
> Date: 12 Mar 2002 21:35:54 +0000
> 
> Rather than putting a note in PROBLEMS specific to %h on Windows, it
> might be better to modify the doc-string for format-time-string, to
> make it clear which specifiers are guaranteed to work, and which are
> POSIX.2 or GNU extensions, and will only work on plaforms that
> support them.

This suggestion is a bit obsolescent, as %h is required by the current
C standard (C99).  And POSIX.2 is now obsolete; it has been folded
into POSIX.1 (as of POSIX 1003.1-2001).

I suggest adding a sentence like "Not all platforms support
locale-specific formats" to the format-time-string doc string; that
will document the general problem.  I don't think it's worth
documenting all the ins and outs of the various standards and
implementations in the format-time-string doc; that will consume too
much space and won't be all that useful.


> Alternatively, we could introduce more conditional blocks to
> strftime.c to do something sensible

That would be a pain to support reliably.  There are lots of little
gotchas in this area.  It's simpler just to let the underlying
strftime handle (or mishandle) locale-related stuff.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Bug in format-time-string in emacs 21.1?

[Jason Rumney]

Paul Eggert <eggert@twinsun.com> writes:

> > Alternatively, we could introduce more conditional blocks to
> > strftime.c to do something sensible
> 
> That would be a pain to support reliably.  There are lots of little
> gotchas in this area.  It's simpler just to let the underlying
> strftime handle (or mishandle) locale-related stuff.

That was my initial impression after reading the code in
strftime.c.  But after experimenting with all the documented format
specifiers, it seems that "%h" is the only one that does not work with
the current code, so some effort has obviously already been made to
make the other specifiers that are not supported by the system
strftime function work.  In the case of "%h", it is documented as
doing the same as "%b", so we can fix that easily.

-- 
Jason Rumney


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Bug in format-time-string in emacs 21.1?

[Paul Eggert]

> From: Jason Rumney <jasonr@gnu.org>
> Date: 12 Mar 2002 22:56:44 +0000
> 
> after experimenting with all the documented format specifiers, it
> seems that "%h" is the only one that does not work with the current code

Surely you not have tested this exhaustively.  That would be quite a
lot of testing.  For example, you would need to test for proper
support of the Modern Japanese Imperial calendar on various versions
of Japanese Windows.  (Not my idea of fun.  :-)


> some effort has obviously already been made to make the other
> specifiers that are not supported by the system strftime function
> work.

I think you may be reading too much into the code here.
Here is a typical bit of code:

	#if defined _NL_CURRENT || !HAVE_STRFTIME
		  cpy (am_len, a_month);
		  break;
	#else
		  goto underlying_strftime;
	#endif

So yes, there is a workaround if the system lacks strftime entirely
(which is quite rare these days).  But that workaround assumes the C
locale, and such a workaround is not reasonable for localized hosts.
If the system has a strftime, the code invokes the system strftime for
locale-specific formats (except for the special case of the GNU C
library, where it uses a faster backdoor _NL_CURRENT).

For example, for the %OY format the system merely invokes the
underlying strftime; if the underlying strftime mishandles %OY then
there is no workaround.  So in this respect, %h is similar to %OY,
%Ea, and lots of other formats.


> In the case of "%h", it is documented as doing the same as "%b", so
> we can fix that easily.

But that will introduce either minor runtime overhead, or
hard-to-maintain Microsoft-version-specific ifdefs, and I doubt
whether either belongs in the GNU C Library source code (which is
where strftime.c lives).

A simpler fix would be for Emacs to stop documenting %h, as it is
redundant.  Or we can simply note the issue in PROBLEMS.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Bug in format-time-string in emacs 21.1?

[Jason Rumney]

Paul Eggert <eggert@twinsun.com> writes:

> > From: Jason Rumney <jasonr@gnu.org>
> > Date: 12 Mar 2002 22:56:44 +0000
> > 
> > after experimenting with all the documented format specifiers, it
> > seems that "%h" is the only one that does not work with the current code
> 
> Surely you not have tested this exhaustively.

I didn't test all the %O and %E permutations, as the documentation
was vague about which format specifiers they are supposed to work
with. It turns out that they do not work on Windows either, though the
symptoms are different; %h returns "", while %OY returns "%OY".

> > some effort has obviously already been made to make the other
> > specifiers that are not supported by the system strftime function
> > work.
> 
> I think you may be reading too much into the code here.

%C, %G, %g, %V are not supported by the underlying library function
either, but they work. That is why I concluded that some effort has
already been made to accommodate systems that do not support those
format specifiers.

> For example, for the %OY format the system merely invokes the
> underlying strftime; if the underlying strftime mishandles %OY then
> there is no workaround.

Perhaps %OY would be better approximated by %Y on systems that do not
support it.  At least the information gets to the user, even if it is
in a different format.


  So in this respect, %h is similar to %OY,
> %Ea, and lots of other formats.
> 
> 
> > In the case of "%h", it is documented as doing the same as "%b", so
> > we can fix that easily.
> 
> But that will introduce either minor runtime overhead, or
> hard-to-maintain Microsoft-version-specific ifdefs,

I don't propose making this Microsoft-specific. There are likely to
be other systems that do not support %h %O and %E, in which case the
same conditional code should be used.

> and I doubt whether either belongs in the GNU C Library source code
> (which is where strftime.c lives).

Really?  Why does the GNU C Library have all that complicated
conditional code to handle the case where it is not the GNU C
Library.  Surely this code would be better separated into the GNU C
Library version (without that code) and the Emacs version (without
the special code for the GNU C Library). Most of the conditional code
could then disappear.


-- 
Jason Rumney


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Bug in format-time-string in emacs 21.1?

[Paul Eggert]

> From: Jason Rumney <jasonr@gnu.org>
> Date: 13 Mar 2002 19:49:35 +0000
> 
> Surely this code would be better separated into the GNU C Library
> version (without that code) and the Emacs version (without the
> special code for the GNU C Library).

It's a tradeoff.  With two copies, there are two copies to maintain
separately.  With one copy, that copy is harder to maintain than
either of the two separate copies.  Which is easier?  It depends on
the case.

For strftime it's probably better to have a single source, as the
incompatibilities between glibc and Emacs are small and are not
intentional.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Bug in format-time-string in emacs 21.1?

[Richard Stallman]

    Alternatively, we could introduce more conditional blocks to
    strftime.c to do something sensible with the POSIX.2 extensions on
    platforms that only support POSIX.1 formats.  I think most of them
    could be handled without too much effort.

If someone wants to do this work, it would clearly give a better
result than documenting flaws.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Bug in format-time-string in emacs 21.1?

[Jason Rumney]

Richard Stallman <rms@gnu.org> writes:

>     Alternatively, we could introduce more conditional blocks to
>     strftime.c to do something sensible with the POSIX.2 extensions on
>     platforms that only support POSIX.1 formats.  I think most of them
>     could be handled without too much effort.
> 
> If someone wants to do this work, it would clearly give a better
> result than documenting flaws.

The following patch makes %h, %EX and %OX do sensible things on
Windows.  Is it worth making configure detect when these fail on
other systems (ie does anyone know of other systems where these might
not work)?


--- strftime.c.~1.25.~	Mon Dec 31 18:26:41 2001
+++ strftime.c	Wed Mar 13 22:01:14 2002
@@ -834,6 +834,13 @@
             size_t strftime ();
 # endif
 
+#ifdef STRFTIME_NO_POSIX2
+	    /* Some system libraries do not support the POSIX.2 extensions.
+	       In those cases, convert %h to %b, and strip modifiers.  */
+	    modifier = 0;
+	    if (format_char == 'h')
+	      format_char = 'b';
+#endif
             *u++ = '%';
             if (modifier != 0)
               *u++ = modifier;


-- 
Jason Rumney


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Bug in format-time-string in emacs 21.1?

[Paul Eggert]

> From: Jason Rumney <jasonr@gnu.org>
> Date: 13 Mar 2002 22:13:33 +0000
> 
> Is it worth making configure detect when these fail on other systems

I don't think it's worth the aggravation.  Any such tests would not
work with cross-compiles anyway.

Your patch looks good (it answered my previous objections).
I'll shepherd it into glibc when I get the time.  There
are a couple of other things to integrate too.

I suspect that newer Microsoft platforms support %h, %EX and %OX, as
ISO C99 requires them.  But it's not critical for Emacs to
autoconfigure to such platforms.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Bug in format-time-string in emacs 21.1?

[Jason Rumney]

Paul Eggert <eggert@twinsun.com> writes:

> I suspect that newer Microsoft platforms support %h, %EX and %OX, as
> ISO C99 requires them.  But it's not critical for Emacs to
> autoconfigure to such platforms.

Visual C++ 6.0 on XP does not support those options. I'm not sure
about the .NET compiler, as far as I know Emacs cannot be compiled
under that yet anyway (every new release of the MS compiler seems to
break unexec somehow).

-- 
Jason Rumney


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel