11:47 p.m.
This was produced with a minimally patched
xemacs-21.4\tests\automated\test-harness.el
and adjusted
build-report-keep-regexp
("^\\(cd\\|n?make\\)\\s-" "errors?" "warnings?"
"pure.*\\(space\\|size\\)" "hides\\b" "strange"
"shadowings" "^Compil\\(ing\\s-+in\\|ation\\)" "^Using"
"not\\s-+found" "^While\\s-+compiling.*\\(
\\s-+.+\\)*" "^Note:" "Installing" "[Ff]ile(s) copied"
"\\s-+tests\\s-+" "^[A-Z] [^ ]+$" "^Wrong number of
arguments:" "^ \\*\\* " "^FAIL:")
and
build-report-delete-regexp
("confl.*with.*auto-inlining" "^Formatting:" "^\\s-+0
.*\\(error\\|failure\\)" "^PASS:")
Patch forthcoming.
Adrian
XEmacs Build Report generated by emacs-version
21.5 (beta15) "celery" XEmacs Lucid
with system-configuration
i586-pc-win32
follows:
Contents of
c:\Hacking\cvs.xemacs.org\XEmacs\xemacs-21.4\Installation:
(Output from most recent run of ./configure)
OS version:
Microsoft Windows 2000 [Version 5.00.2195]
OS: Windows_NT
XEmacs 21.4.14 "Reasonable Discussion" configured for `i586-pc-win32'.
Building XEmacs in "c:\\Hacking\\cvs.xemacs.org\\XEmacs\\xemacs-21.4\\nt".
Using compiler "cl -nologo -W3 -O2 -G5 -MD".
Installing XEmacs in "c:\\Program Files\\XEmacs\\XEmacs-21.4.14".
Package path is "~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program
Files\\XEmacs\\xemacs-packages".
Compiling in support for Microsoft Windows native GUI.
Compiling in support for XPM images.
Compiling in support for GIF images.
Compiling in support for PNG images.
Compiling in support for TIFF images.
Compiling in support for JPEG images.
Compiling in support for X-Face message headers.
Compiling in support for toolbars.
Compiling in support for dialogs.
Compiling in support for widgets.
Compiling in support for native sounds.
Compiling in fast dired implementation.
Using portable dumper.
Using system malloc.
Using DLL version of C runtime library
Contents of
c:\Hacking\cvs.xemacs.org\XEmacs\xemacs-21.4\xemacs-21.4-cvs-update-release-21-4.err
keeping lines matching
"^--\[\[\|\]\]$\|^\(cd\|n?make\)\s-\|errors?\|warnings?\|pure.*\(space\|size\)\|hides\b\|strange\|shadowings\|^Compil\(ing\s-+in\|ation\)\|^Using\|not\s-+found\|^While\s-+compiling.*\(
\s-+.+\)*\|^Note:\|Installing\|[Ff]ile(s) copied\|\s-+tests\s-+\|^[A-Z] [^
]+$\|^Wrong number of arguments:\|^ \*\* \|^FAIL:"
and then deleting lines matching
"confl.*with.*auto-inlining\|^Formatting:\|^\s-+0 .*\(error\|failure\)\|^PASS:"
cd c:\Hacking\cvs.xemacs.org\XEmacs\xemacs-21.4\
Compilation started at Mon Sep 08 23:16:29 2003 +0200 (CES)
M nt/installer/Wise/xemacs.tmpl
cvs server: Updating tests
cvs server: Updating tests/DLL
Compilation finished at Mon Sep 08 23:18:11
Contents of
c:\Hacking\cvs.xemacs.org\XEmacs\xemacs-21.4\nt\xemacs-21.4-make-install.err
keeping lines matching
"^--\[\[\|\]\]$\|^\(cd\|n?make\)\s-\|errors?\|warnings?\|pure.*\(space\|size\)\|hides\b\|strange\|shadowings\|^Compil\(ing\s-+in\|ation\)\|^Using\|not\s-+found\|^While\s-+compiling.*\(
\s-+.+\)*\|^Note:\|Installing\|[Ff]ile(s) copied\|\s-+tests\s-+\|^[A-Z] [^
]+$\|^Wrong number of arguments:\|^ \*\* \|^FAIL:"
and then deleting lines matching
"confl.*with.*auto-inlining\|^Formatting:\|^\s-+0 .*\(error\|failure\)\|^PASS:"
cd c:\Hacking\cvs.xemacs.org\XEmacs\xemacs-21.4\nt\
nmake /f xemacs.mak install
Compilation started at Mon Sep 08 23:54:25 2003 +0200 (CES)
Installing XEmacs in "c:\\Program Files\\XEmacs\\XEmacs-21.4.14".
Using load-path (c:\Hacking\cvs.xemacs.org\XEmacs\xemacs-21.4\lisp)
Using module-load-path (c:\Hacking\cvs.xemacs.org\XEmacs\xemacs-21.4\modules)
Note: Strange doc (not fboundp) for function user-name-completion-1 ＠ 623303
Note: Strange doc (not fboundp) for function user-name-all-completions ＠ 623627
Installing in c:\Program Files\XEmacs\XEmacs-21.4.14 ...
1 File(s) copied
1 File(s) copied
11 File(s) copied
1 file(s) copied.
1 file(s) copied.
1 file(s) copied.
430 File(s) copied
132 File(s) copied
493 File(s) copied
1 File(s) copied
1 File(s) copied
1 File(s) copied
Compilation finished at Mon Sep 08 23:56:40
Contents of
c:\Hacking\cvs.xemacs.org\XEmacs\xemacs-21.4\nt\xemacs-21.4-make-check-temacs.err
keeping lines matching
"^--\[\[\|\]\]$\|^\(cd\|n?make\)\s-\|errors?\|warnings?\|pure.*\(space\|size\)\|hides\b\|strange\|shadowings\|^Compil\(ing\s-+in\|ation\)\|^Using\|not\s-+found\|^While\s-+compiling.*\(
\s-+.+\)*\|^Note:\|Installing\|[Ff]ile(s) copied\|\s-+tests\s-+\|^[A-Z] [^
]+$\|^Wrong number of arguments:\|^ \*\* \|^FAIL:"
and then deleting lines matching
"confl.*with.*auto-inlining\|^Formatting:\|^\s-+0 .*\(error\|failure\)\|^PASS:"
cd c:\Hacking\cvs.xemacs.org\XEmacs\xemacs-21.4\nt\
nmake /f xemacs.mak check-temacs
Compilation started at Tue Sep 09 00:15:33 2003 +0200 (CES)
Using load-path (c:\Hacking\cvs.xemacs.org\XEmacs\xemacs-21.4\lisp)
Using module-load-path (c:\Hacking\cvs.xemacs.org\XEmacs\xemacs-21.4\modules)
Note: Strange doc (not fboundp) for function user-name-completion-1 ＠ 623303
Note: Strange doc (not fboundp) for function user-name-all-completions ＠ 623627
base64-tests.el: 1232 of 1232 tests successful (100%).
byte-compiler-tests.el: 104 of 104 tests successful (100%).
c-tests.el: No tests run
case-tests.el: 1118 of 1118 tests successful (100%).
ccl-tests.el: No tests run
database-tests.el: No tests run
extent-tests.el: 194 of 194 tests successful (100%).
hash-table-tests.el: 9866 of 9866 tests successful (100%).
lisp-tests.el: 3588 of 3604 tests successful (99%).
FAIL: Assertion failed: (string= (format "%e" 100) "1.000000e+02")
FAIL: Assertion failed: (string= (format "%E" 100) "1.000000E+02")
FAIL: Assertion failed: (string= (format "%g" 1e-006) "1e-06")
FAIL: Assertion failed: (string= (format "%G" 1e-006) "1E-06")
FAIL: Assertion failed: (string= (format "%#e" 100) "1.000000e+02")
FAIL: Assertion failed: (string= (format "%#E" 100) "1.000000E+02")
FAIL: Assertion failed: (string= (format "%#g" 1e-006) "1.00000e-06")
FAIL: Assertion failed: (string= (format "%#G" 1e-006) "1.00000E-06")
FAIL: Assertion failed: (string= (format "%e" 100) "1.000000e+02")
FAIL: Assertion failed: (string= (format "%E" 100) "1.000000E+02")
FAIL: Assertion failed: (string= (format "%g" 1e-006) "1e-06")
FAIL: Assertion failed: (string= (format "%G" 1e-006) "1E-06")
FAIL: Assertion failed: (string= (format "%#e" 100) "1.000000e+02")
FAIL: Assertion failed: (string= (format "%#E" 100) "1.000000E+02")
FAIL: Assertion failed: (string= (format "%#g" 1e-006) "1.00000e-06")
FAIL: Assertion failed: (string= (format "%#G" 1e-006) "1.00000E-06")
md5-tests.el: 56 of 56 tests successful (100%).
mule-tests.el: 2 of 2 tests successful (100%).
regexp-tests.el: 176 of 176 tests successful (100%).
symbol-tests.el: 264 of 264 tests successful (100%).
syntax-tests.el: 64 of 64 tests successful (100%).
Compilation finished at Tue Sep 09 00:16:57
Contents of
c:\Hacking\cvs.xemacs.org\XEmacs\xemacs-21.4\nt\xemacs-21.4-make-check.err
keeping lines matching
"^--\[\[\|\]\]$\|^\(cd\|n?make\)\s-\|errors?\|warnings?\|pure.*\(space\|size\)\|hides\b\|strange\|shadowings\|^Compil\(ing\s-+in\|ation\)\|^Using\|not\s-+found\|^While\s-+compiling.*\(
\s-+.+\)*\|^Note:\|Installing\|[Ff]ile(s) copied\|\s-+tests\s-+\|^[A-Z] [^
]+$\|^Wrong number of arguments:\|^ \*\* \|^FAIL:"
and then deleting lines matching
"confl.*with.*auto-inlining\|^Formatting:\|^\s-+0 .*\(error\|failure\)\|^PASS:"
cd c:\Hacking\cvs.xemacs.org\XEmacs\xemacs-21.4\nt\
nmake /f xemacs.mak check
Compilation started at Tue Sep 09 00:30:26 2003 +0200 (CES)
base64-tests.el: 1232 of 1232 tests successful (100%).
byte-compiler-tests.el: 104 of 104 tests successful (100%).
c-tests.el: No tests run
case-tests.el: 1118 of 1118 tests successful (100%).
ccl-tests.el: No tests run
database-tests.el: No tests run
extent-tests.el: 194 of 194 tests successful (100%).
hash-table-tests.el: 9866 of 9866 tests successful (100%).
lisp-tests.el: 3588 of 3604 tests successful (99%).
FAIL: Assertion failed: (string= (format "%e" 100) "1.000000e+02")
FAIL: Assertion failed: (string= (format "%E" 100) "1.000000E+02")
FAIL: Assertion failed: (string= (format "%g" 1e-006) "1e-06")
FAIL: Assertion failed: (string= (format "%G" 1e-006) "1E-06")
FAIL: Assertion failed: (string= (format "%#e" 100) "1.000000e+02")
FAIL: Assertion failed: (string= (format "%#E" 100) "1.000000E+02")
FAIL: Assertion failed: (string= (format "%#g" 1e-006) "1.00000e-06")
FAIL: Assertion failed: (string= (format "%#G" 1e-006) "1.00000E-06")
FAIL: Assertion failed: (string= (format "%e" 100) "1.000000e+02")
FAIL: Assertion failed: (string= (format "%E" 100) "1.000000E+02")
FAIL: Assertion failed: (string= (format "%g" 1e-006) "1e-06")
FAIL: Assertion failed: (string= (format "%G" 1e-006) "1E-06")
FAIL: Assertion failed: (string= (format "%#e" 100) "1.000000e+02")
FAIL: Assertion failed: (string= (format "%#E" 100) "1.000000E+02")
FAIL: Assertion failed: (string= (format "%#g" 1e-006) "1.00000e-06")
FAIL: Assertion failed: (string= (format "%#G" 1e-006) "1.00000E-06")
md5-tests.el: 56 of 56 tests successful (100%).
mule-tests.el: 2 of 2 tests successful (100%).
regexp-tests.el: 176 of 176 tests successful (100%).
symbol-tests.el: 264 of 264 tests successful (100%).
syntax-tests.el: 64 of 64 tests successful (100%).
Compilation finished at Tue Sep 09 00:30:59
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/
7:10 a.m.
>>>> "APA" == Adrian Aichner
<Adrian.Aichner(a)t-online.de> writes:
APA> FAIL: Assertion failed: (string= (format "%e" 100)
"1.000000e+02")
Oops, oh, yeah, that too.
Funny how those Windows bugs never get fixed. There was a bunch of
discussion about this, but never any resolution. Are you going to
change the tests, or not?
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
2:37 p.m.
>>>> "Stephen" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
>>>> "APA" == Adrian Aichner
<Adrian.Aichner(a)t-online.de> writes:
APA> FAIL: Assertion failed:
(string= (format "%e" 100) "1.000000e+02")
Stephen> Oops, oh, yeah, that too.
Stephen> Funny how those Windows bugs never get fixed. There was
Stephen> a bunch of discussion about this, but never any
Stephen> resolution. Are you going to change the tests, or not?
Hi Stephen, I forgot all about these failures because they were
invisible until now. I don't run these tests interactively, but my
own build reports may make me do so in the future.
What are you suggesting for this particular problem?
Making these failure expected when running on native windows?
Convincing Microsoft to give up breaking software standards to foster
their monopoly?
Put a fix into XEmacs sources for format to work right in native
Windows?
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/
8:29 p.m.
>>>> "APA" == Adrian Aichner
<adrian(a)xemacs.org> writes:
>>>> "Stephen" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
>>>> "APA" == Adrian Aichner <Adrian.Aichner(a)t-online.de>
writes:
APA> FAIL: Assertion failed: (string= (format "%e" 100)
"1.000000e+02")
Stephen> Oops, oh, yeah, that too.
Stephen> Funny how those Windows bugs never get fixed. There was
Stephen, I looked into this a bit.
These tests all fail because of a three digit exponent being printed
by MS printf.
Using cygwin I get two-digit exponents printed instead of three.
However, reading
http://www.opengroup.org/onlinepubs/007904975/functions/printf.html
seems to suggest that three digit exponents are not in violation with
the following excerpt:
e, E
The double argument shall be converted in the style "[-]d.ddde±dd", where there
is one digit before the radix character (which is non-zero if the argument is non-zero)
and the number of digits after it is equal to the precision; if the precision is missing,
it shall be taken as 6; if the precision is zero and no '#' flag is present, no
radix character shall appear. The low-order digit shall be rounded in an
implementation-defined manner. The E conversion specifier shall produce a number with
'E' instead of 'e' introducing the exponent. The exponent shall always
contain at least two digits. If the value is zero, the exponent shall be zero.
A double argument representing an infinity or NaN shall be converted in the style of an f
or F conversion specifier.
Should the testcase allow three-digit as well as two-digit exponents?
Is anyone aware that we rely on two-digit exponents anywhere?
Adrian, having spent way too much time on this already ...
Stephen> a bunch of discussion about this, but never any
Stephen> resolution. Are you going to change the tests, or not?
APA> Hi Stephen, I forgot all about these failures because they were
APA> invisible until now. I don't run these tests interactively, but my
APA> own build reports may make me do so in the future.
APA> What are you suggesting for this particular problem?
APA> Making these failure expected when running on native windows?
APA> Convincing Microsoft to give up breaking software standards to foster
APA> their monopoly?
APA> Put a fix into XEmacs sources for format to work right in native
APA> Windows?
APA> --
APA> Adrian Aichner
APA> mailto:adrian＠xemacs.org
APA> http://www.xemacs.org/
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/
12:04 a.m.
Adrian Aichner wrote:
APA> FAIL: Assertion failed: (string= (format "%e"
100) "1.000000e+02")
Stephen> Oops, oh, yeah, that too.
Stephen> Funny how those Windows bugs never get fixed. There was
Stephen, I looked into this a bit.
These tests all fail because of a three digit exponent being printed
by MS printf.
Using cygwin I get two-digit exponents printed instead of three.
However, reading
http://www.opengroup.org/onlinepubs/007904975/functions/printf.html
seems to suggest that three digit exponents are not in violation with
the following excerpt:
e, E
The double argument shall be converted in the style "[-]d.ddde±dd",
where there is one digit before the radix character (which is non-zero
if the argument is non-zero) and the number of digits after it is
equal to the precision; if the precision is missing, it shall be taken
as 6; if the precision is zero and no '#' flag is present, no radix
character shall appear. The low-order digit shall be rounded in an
implementation-defined manner. The E conversion specifier shall
produce a number with 'E' instead of 'e' introducing the exponent. The
exponent shall always contain at least two digits. If the value is
zero, the exponent shall be zero.
A double argument representing an infinity or NaN shall be converted
in the style of an f or F conversion specifier.
That's almost identical to the ANSI C specification, but not quite:
e,E A double argument representing a (finite) floating- |
point number is converted in the style [-]d.ddde±dd,
where there is one digit (which is nonzero if the
argument is nonzero) before the decimal-point
character and the number of digits after it is equal
to the precision; if the precision is missing, it is
taken as 6; if the precision is zero and the # flag
is not specified, no decimal-point character
appears. The value is rounded to the appropriate
number of digits. The E conversion specifier
produces a number with E instead of e introducing
the exponent. The exponent always contains at least
two digits, AND ONLY AS MANY MORE DIGITS AS
NECESSARY TO REPRESENT THE EXPONENT. If the value
is zero, the exponent is zero.
A double argument representing an infinity or NaN is
converted in the style of an f or F conversion
specifier.
[Emphasis mine.]
IOW, the MSVC printf() may be compatible with Unix98, but it isn't
compatible with ANSI C.
However, this is the specification of the C *printf functions; nothing
requires that the elisp "format" function behaves similarly. FWIW, the
lispref Info file just says:
`%e'
Replace the specification with the exponential notation for a
floating point number (e.g. `7.85200e+03').
It doesn't include any claims of compatibility with C's *printf
family; or even a mention of them, for that matter.
Given that we don't appear to be under any obligation to mimic the
ANSI C semantics, I can't see any harm in defining the semantics of
the %e specifier in such a way that it can be implemented using MSVC's
sprintf().
--
Glynn Clements <glynn.clements(a)virgin.net>
6:08 p.m.
>>>> "Glynn" == Glynn Clements
<glynn.clements(a)virgin.net> writes:
Glynn> Given that we don't appear to be under any obligation to
Glynn> mimic the ANSI C semantics, I can't see any harm in
Glynn> defining the semantics of the %e specifier in such a way
Glynn> that it can be implemented using MSVC's sprintf().
You don't? That would make the results of an elisp program needlessly
platform-dependent.
＠defun format string &rest objects
... The %e specifier takes a floating point value, and formats it in
scientific notation. For portable use of this specifier, you must
test for platform; for exponents in the range -99 to +99 this field
will be 1 column wider if XEmacs was compiled with MSVC. ...
That just ain't right. It's hard enough to format nice tables as it
is.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
6:40 p.m.
>>>> "Stephen" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
>>>> "Glynn" == Glynn Clements
<glynn.clements(a)virgin.net> writes:
Glynn> Given that we don't
appear to be under any obligation to
Glynn> mimic the ANSI C semantics, I can't see any harm in
Glynn> defining the semantics of the %e specifier in such a way
Glynn> that it can be implemented using MSVC's sprintf().
Stephen> You don't? That would make the results of an elisp
Stephen> program needlessly platform-dependent.
Stephen> ＠defun format string &rest objects
Stephen> ... The %e specifier takes a floating point value, and
Stephen> formats it in scientific notation. For portable use of
Stephen> this specifier, you must test for platform; for exponents
Stephen> in the range -99 to +99 this field will be 1 column wider
Stephen> if XEmacs was compiled with MSVC. ...
Stephen> That just ain't right. It's hard enough to format nice
Stephen> tables as it is.
Well, yes, but even
http://www.opengroup.org/onlinepubs/007904975/functions/printf.html
doesn't specify this requirement clearly.
A draft of C9X, OTOH, which I was able to find, states:
the exponent. The exponent always contains at least
two digits, and only as many more digits as
necessary to represent the exponent. If the value
What online resources should we be reading for stuff like this?
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/
5:11 a.m.
>>>> "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).
We want to follow the tightest spec that is admissible under other specs.
We _want_ a tight spec for functions we maintain according to the "be
strict in what you produce, permissive in what you accept" principle.
This means that XEmacs can interoperate with the widest variety of 3rd
party software.
For example, it is not righteous to ask the author of "table.el" to do
an extra check for "MSVC" when computing the width of a field to be
specified as "%e". If that author expects that most of the time
exponents will be two digits, even if he is willing to accept breakage
in cases where three digits are needed, he will probably not be
pleased with the flood of reports from MS users that unless a column
consists _only_ of floats the column alignment is _always_ broken. He
will justifiably consider it an XEmacs bug.
I'd like to just deprecate the platform, because I'm getting sick of
seeing XEmacs go bughouse every time the penetration rate of the most
recent MS OS or compiler offering surges, and we get nowhere near the
patch/bitch ratio for MS ports that we do for the Un*x platforms. I
don't mind supporting users, but with both Andy and Ben currently out
of the picture, this is an unfair burden on non-MS-using XEmacs
developers.
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.
APA> What online resources should we be reading for stuff like
APA> this?
All of 'em. ;-) Well, Martin recommended
POSIX http://www.opengroup.org/onlinepubs/007908799/
C99 http://wwwold.dkuug.dk/jtc1/sc22/open/n2794/
("final committee draft", cf
http://home.tiscalinet.ch/t_wolf/tw/c/c9x_changes.html)
but most important is
http://list-archive.xemacs.org/build-reports/
which has no examples AFAICS of this test failing on any platform
other than Microsoft VC. That means that we're pretty safe in
assuming conformance, except from a platform which has really dismal
historical performance vis-a-vis standards conformance in any case.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
10:29 a.m.
"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.
3:11 p.m.
>>>> "Hrvoje" == Hrvoje Niksic
<hniksic(a)xemacs.org> writes:
Hrvoje> What does C89 say about this? I suspect MS (and Unix98)
Hrvoje> might have followed an older, more permissive standard.
Heh. Several hundred USD plus postage will get you the answer to that.
All Google could find was a couple dozen posts saying "no, C89 now
only exists on paper."
> We want to follow the tightest spec that is admissible under
> other specs.
Hrvoje> Yes, if by follow you mean "use or implement where
Hrvoje> unavailable".
That's what I meant by "follow".
This still leaves the question of "who does the implementation" up for
debate. It's probably not going to be me.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
4:37 p.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
>>>>> "Hrvoje" == Hrvoje Niksic
<hniksic(a)xemacs.org> writes:
Hrvoje> What does C89 say about this? I suspect MS (and Unix98)
Hrvoje> might have followed an older, more permissive standard.
Heh. Several hundred USD plus postage will get you the answer to that.
All Google could find was a couple dozen posts saying "no, C89 now
only exists on paper."
Amazing. For some reason, I cannot even find the pre-C89 draft that
was floating around. I can't believe they issued cease-and-desists
for that one!
7732
days inactive
7739
days old
10 comments
5 participants
participants (5)
-
Adrian Aichner -
Adrian Aichner -
Glynn Clements -
Hrvoje Niksic -
Stephen J. Turnbull