Re: [Success/exposed test failures] XEmacs 21.4.14 "Reasonable Discussion" i586-pc-win32
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
>>>>> "APA" == Adrian Aichner
<adrian(a)xemacs.org> writes:
APA> Well, yes, but even
APA> http://www.opengroup.org/onlinepubs/007904975/functions/printf.html
APA> doesn't specify this requirement clearly.
Sure. There is a widely-respected standard which does, however
(C99).
C99 is still pretty far from widely-respected, at least for my
definition of "widely". What does C89 say about this? I suspect MS
(and Unix98) might have followed an older, more permissive standard.
However, I do agree with the rest of your `table.el' reasoning. There
are countless examples of "be lenient with what you receive, be strict
in what you generate" strategy XEmacs -- for example, our
`atoi'-equivalent strips spaces before the number because some atoi's
don't do that, and we want to be compatible with ourselves.
We want to follow the tightest spec that is admissible under other
specs.
Yes, if by follow you mean "use or implement where unavailable".
Historically, XEmacs has not required a strict ANSI C library.
Compiler, yes, library, no. God knows we've supported all kinds of
junk on Unix systems, from missing memcpy to breakage of every system
call under the sun.
Since that's not acceptable to many Windows-based XEmacs users,
and
won't prevent the bug reports in any case, I think we should
reimplement the %e spec internally for use by "non-conforming"
platforms. A simple filter that checks for extra leading zeros in
the output of the %e implementation, and strips them, would be fine.
We should also implement the (easy) configure check to enable it in
case another platform follows MS.
This sounds good to me. It's in the spirit of how XEmacs (and most
GNU software) typically deals with portability issues.