* Re: Bug in format-time-string in emacs 21.1? [not found] ` <m3n0xep8u8.fsf@Janik.cz> @ 2002-03-12 21:35 ` Jason Rumney 2002-03-12 22:21 ` Paul Eggert 2002-03-13 10:59 ` Richard Stallman 0 siblings, 2 replies; 10+ messages in thread From: Jason Rumney @ 2002-03-12 21:35 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Bug in format-time-string in emacs 21.1? 2002-03-12 21:35 ` Bug in format-time-string in emacs 21.1? Jason Rumney @ 2002-03-12 22:21 ` Paul Eggert 2002-03-12 22:56 ` Jason Rumney 2002-03-13 10:59 ` Richard Stallman 1 sibling, 1 reply; 10+ messages in thread From: Paul Eggert @ 2002-03-12 22:21 UTC (permalink / raw) Cc: emacs-devel > 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Bug in format-time-string in emacs 21.1? 2002-03-12 22:21 ` Paul Eggert @ 2002-03-12 22:56 ` Jason Rumney 2002-03-12 23:37 ` Paul Eggert 0 siblings, 1 reply; 10+ messages in thread From: Jason Rumney @ 2002-03-12 22:56 UTC (permalink / raw) Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Bug in format-time-string in emacs 21.1? 2002-03-12 22:56 ` Jason Rumney @ 2002-03-12 23:37 ` Paul Eggert 2002-03-13 19:49 ` Jason Rumney 0 siblings, 1 reply; 10+ messages in thread From: Paul Eggert @ 2002-03-12 23:37 UTC (permalink / raw) Cc: emacs-devel > 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Bug in format-time-string in emacs 21.1? 2002-03-12 23:37 ` Paul Eggert @ 2002-03-13 19:49 ` Jason Rumney 2002-03-14 0:37 ` Paul Eggert 0 siblings, 1 reply; 10+ messages in thread From: Jason Rumney @ 2002-03-13 19:49 UTC (permalink / raw) Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Bug in format-time-string in emacs 21.1? 2002-03-13 19:49 ` Jason Rumney @ 2002-03-14 0:37 ` Paul Eggert 0 siblings, 0 replies; 10+ messages in thread From: Paul Eggert @ 2002-03-14 0:37 UTC (permalink / raw) Cc: emacs-devel > 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Bug in format-time-string in emacs 21.1? 2002-03-12 21:35 ` Bug in format-time-string in emacs 21.1? Jason Rumney 2002-03-12 22:21 ` Paul Eggert @ 2002-03-13 10:59 ` Richard Stallman 2002-03-13 22:13 ` Jason Rumney 1 sibling, 1 reply; 10+ messages in thread From: Richard Stallman @ 2002-03-13 10:59 UTC (permalink / raw) Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Bug in format-time-string in emacs 21.1? 2002-03-13 10:59 ` Richard Stallman @ 2002-03-13 22:13 ` Jason Rumney 2002-03-14 0:13 ` Paul Eggert 0 siblings, 1 reply; 10+ messages in thread From: Jason Rumney @ 2002-03-13 22:13 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Bug in format-time-string in emacs 21.1? 2002-03-13 22:13 ` Jason Rumney @ 2002-03-14 0:13 ` Paul Eggert 2002-03-14 22:28 ` Jason Rumney 0 siblings, 1 reply; 10+ messages in thread From: Paul Eggert @ 2002-03-14 0:13 UTC (permalink / raw) Cc: emacs-devel > 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Bug in format-time-string in emacs 21.1? 2002-03-14 0:13 ` Paul Eggert @ 2002-03-14 22:28 ` Jason Rumney 0 siblings, 0 replies; 10+ messages in thread From: Jason Rumney @ 2002-03-14 22:28 UTC (permalink / raw) Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2002-03-14 22:28 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <Pine.SUN.3.91.1020312075746.24908F-100000@is> [not found] ` <m3n0xep8u8.fsf@Janik.cz> 2002-03-12 21:35 ` Bug in format-time-string in emacs 21.1? Jason Rumney 2002-03-12 22:21 ` Paul Eggert 2002-03-12 22:56 ` Jason Rumney 2002-03-12 23:37 ` Paul Eggert 2002-03-13 19:49 ` Jason Rumney 2002-03-14 0:37 ` Paul Eggert 2002-03-13 10:59 ` Richard Stallman 2002-03-13 22:13 ` Jason Rumney 2002-03-14 0:13 ` Paul Eggert 2002-03-14 22:28 ` Jason Rumney
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).