>>>>"AA" == Adrian Aichner
<adrian.aichner(a)gmail.com> writes:
AA> How could XEmacs and GNU Emacs both
be wrong until now?
XEmacs wasn't wrong for long, this caused the problem:
changeset: 5762:427a72c6ee17
user: Stephen J. Turnbull <stephen(a)xemacs.org>
date: Sun Sep 15 23:47:37 2013 +0900
summary: Eliminate several compiler (clang) warnings.
diff --git a/src/editfns.c b/src/editfns.c
--- a/src/editfns.c
+++ b/src/editfns.c
@@ -1190,7 +1190,9 @@
else if (FIXNUMP (zone))
{
int abszone = abs (XFIXNUM (zone));
- sprintf (tzbuf, "XXX%s%d:%02d:%02d", "-" + (XFIXNUM (zone)
< 0),
+ /* #### I have no idea what this conforms to,
+ but the compiler has stopped whining. */
+ sprintf (tzbuf, "XXX%s%d:%02d:%02d", (XFIXNUM (zone) < 0) ?
"-" : "+",
abszone / (60*60), (abszone/60) % 60, abszone % 60);
tzstring = tzbuf;
}
AA>
http://git.savannah.gnu.org/cgit/emacs.git/tree/src/editfns.c#n1937
AA> suggests that they are not including a + character for positive offsets,
AA> which surprised me.
According to `man tzset', the + character is optional. I prefer to make
it explicit to avoid confusion.
AA> But zone offsets > 0 do not include the - sign, which is the same logic
AA> XEmacs uses before your patch.
No, it is not. GNU Emacs is correct, but it's implementation is a
rather hacky array access: &"-"[XINT (zone) < 0]
A negative zone offset yields &"-"[1], which skips the minus and yields
the empty string; a zero or positive zone offset yields the minus via
&"-"[0].
AA> Also, why are you removing the REST argument in passing without mention?
That was a misunderstanding on my part, sorry for that.
--
Marcus
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-patches