search

Perl / perl5

🐪 The Perl programming language
https://dev.perl.org/perl5/
Other
1.92k stars 549 forks source link

Not OK: perl v5.7.0 +DEVEL7158 on os390 05.00 (UNINSTALLED) #2688

Closed p5pRT closed 20 years ago

p5pRT commented 24 years ago

Migrated from rt.perl.org#4401 (status was 'resolved')

Searchable as RT4401$

p5pRT commented 24 years ago

From pvhp@forte.com

This was an out of the box build attempt on OS/390 R2.5 using the perl@​7159.tgz tarball. Configure went smoothly\, the build sailed through ext/Socket/ just fine(?)\, and the only test failures seen were along the lines of​:

FAILED at test 13 comp/script..........ok

op/oct...............FAILED at test 40

op/regmesg...........Malformed UTF-8 character at (eval 20) line 1. \ FAILED at test 19

op/sprintf...........FAILED at test 11

op/substr............FAILED at test 130

op/tr................Malformed UTF-8 character at op/tr.t line 72. \ CEE5213S The signal SIGPIPE was received. FAILED at test 8

op/ver...............FAILED at test 5

pragma/locale........Unmatched [ before HERE mark in regex m/[ \<\< HERE / at pra. FAILED at test 99

pragma/warnings......PROG​: # pp.c use utf8 ; $_ = "\x80 \xff" ; reverse ; EXPECT EXPECTED​:

GOT​: Malformed UTF-8 character at - line 3. Malformed UTF-8 character at - line 3. Malformed UTF-8 character at - line 3. Malformed UTF-8 character at - line 3. Malformed UTF-8 character at - line 4. CEE5213S The signal SIGPIPE was received. FAILED at test 84

lib/b................CEE5213S The signal SIGPIPE was received. FAILED at test 8

lib/bigfloat.........CEE5213S The signal SIGPIPE was received. FAILED at test 351 lib/bigfltpm.........CEE5213S The signal SIGPIPE was received. FAILED at test 358

lib/cgi-function.....CEE5213S The signal SIGPIPE was received. FAILED at test 25 lib/cgi-html.........CEE5213S The signal SIGPIPE was received. FAILED at test 22

lib/charnames........Malformed UTF-8 character at lib/charnames.t line 86. \ FAILED at test 13

lib/encode...........Out of memory! Callback called exit at ../lib/unicode/Name.pl line 5585. FAILED at test 0

lib/io_multihomed....EDC8103I Operation now in progress. at lib/io_multihomed.t. FAILED at test 6

lib/io_unix..........Can't call method "getline" on an undefined value at lib/i. FAILED at test 3

lib/st-06compat......Can't call method "ref" on unblessed reference at lib/st-0. FAILED at test 3

lib/syslog...........FAILED at test 6

Failed 20 test scripts out of 252\, 92.06% okay.

Woo hoo! Many thanks Simon!

Perl Info ``` Flags: category=install severity=none Site configuration information for perl v5.7.0: Configured by PVHP at Fri Oct 6 10:48:09 PDT 2000. Summary of my perl5 (revision 5.0 version 7 subversion 0) configuration: Platform: osname=os390, osvers=05.00, archname=os390 uname='os390 lpar25 05.00 02 9672 ' config_args='-Dusedevel -des' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=undef d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef Compiler: cc='c89', ccflags ='-DMAXSIG=38 -DOEMVS -D_OE_SOCKETS -D_XOPEN_SOURCE_EXTENDED -D_ALL_SOURCE -DYYDYNAMIC -I/usr/local/include', optimize=' ', cppflags='' ccversion='', gccversion='', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321 d_longlong=undef, longlongsize=, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=4 alignbytes=8, usemymalloc=n, prototype=define Linker and Libraries: ld='ld', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lm -lc libc=, so=a, useshrplib=false, libperl=libperl.a Dynamic Linking: dlsrc=dl_none.xs, dlext=none, d_dlsymun=undef, ccdlflags='' cccdlflags='-W 0,dll,"langlvl(extended)"', lddlflags='' Locally applied patches: DEVEL7158 @INC for perl v5.7.0: lib /usr/local/lib/perl5/5.7.0/os390 /usr/local/lib/perl5/5.7.0 /usr/local/lib/perl5/site_perl/5.7.0/os390 /usr/local/lib/perl5/site_perl/5.7.0 /usr/local/lib/perl5/site_perl/5.005/os390 /usr/local/lib/perl5/site_perl/5.005 /usr/local/lib/perl5/site_perl . Environment for perl v5.7.0: HOME=/home/pvhp LANG=C LANGUAGE (unset) LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=/usr/local/bin:/bin:.:/usr/bin PERL_BADLANG (unset) SHELL=/bin/sh ```
p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

At 12​:00 -0700 2000-10-06\, Peter Prymmer wrote​:

op/sprintf...........FAILED at test 11

Hmmm. That means

sprintf "%G"\, 1234567e96

does not produce 1.23457E+102 (although\, perhaps unexpectedly\, a later test of

sprintf "%g"\, 1234567e96

does produce 1.234567e+102). Could you do

cd t; ./perl op/sprintf.t

and send me the output for the failing test? Thanks.

p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

On Sat\, 7 Oct 2000\, Dominic Dunlop wrote​:

At 12​:00 -0700 2000-10-06\, Peter Prymmer wrote​:

op/sprintf...........FAILED at test 11

Hmmm. That means

sprintf "%G"\, 1234567e96

does not produce 1.23457E+102 (although\, perhaps unexpectedly\, a later test of

sprintf "%g"\, 1234567e96

does produce 1.234567e+102). Could you do

cd t; ./perl op/sprintf.t

and send me the output for the failing test? Thanks.

Here you are​:

$ ./perl op/sprintf.t 1..207 \ ok 10 not ok 11 >%G\< >1234567e96\< >1.23457E+102\< >7.23701E+75\< not ok 12 >%G\< >.1234567e-101\< >1.23457E-102\< >0\< ok 13 \ ok 89 not ok 90 >%e\< >1234567E96\< >1.234567e+102\< >7.237006e+75\< ok 91 not ok 92 >%e\< >.1234567E-101\< >1.234567e-102\< >0.000000e+00\< =>

0.000000e+0\< ok 93 \ ok 155 not ok 156 >%g\< >1234567E96\< >1.23457e+102\< >7.23701e+75\< not ok 157 >%g\< >.1234567E-101\< >1.23457e-102\< >0\< ok 158 \

Peter Prymmer

p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

At 10​:05 -0700 2000-10-09\, Peter Prymmer wrote​:

Here you are​:

$ ./perl op/sprintf.t 1..207 \ ok 10 not ok 11 >%G\< >1234567e96\< >1.23457E+102\< >7.23701E+75\<

Gasp! That's horrible. Value > DBL_MAX represented HUGE_VAL maybe? (That's what ANSI C says the strtod() function can do (setting errno if it does so)\, but perl doesn't use strtod()).

not ok 12 >%G\< >.1234567e-101\< >1.23457E-102\< >0\<

That's less horrible.

Oh dear. What values does /usr/include/float.h (or moral equivalent) give for DBL_MAX and DBL_MIN? I made the assumption that allowing the modulus of the exponent to creep just beyond a hundred was OK\, even though good old ANSI C allows an implementation to get away with just 37.

p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

On Mon\, 9 Oct 2000\, Dominic Dunlop wrote​:

At 10​:05 -0700 2000-10-09\, Peter Prymmer wrote​:

Here you are​:

$ ./perl op/sprintf.t 1..207 \ ok 10 not ok 11 >%G\< >1234567e96\< >1.23457E+102\< >7.23701E+75\<

Gasp! That's horrible. Value > DBL_MAX represented HUGE_VAL maybe? (That's what ANSI C says the strtod() function can do (setting errno if it does so)\, but perl doesn't use strtod()).

The OS/390 strtod() is documented to​:

Returns the value of the floating-point number\, except when the representation causes an underflow or overflow. In an overflow\, it returns -HUGE_VAL or +HUGE_VAL. In an underflow\, it returns the value 0. If no conversion is performed\, strtod() returns the value 0. In both cases\, errno is set to ERANGE\, depending on the base of the value.

not ok 12 >%G\< >.1234567e-101\< >1.23457E-102\< >0\<

That's less horrible.

Oh dear. What values does /usr/include/float.h (or moral equivalent) give for DBL_MAX and DBL_MIN? I made the assumption that allowing the modulus of the exponent to creep just beyond a hundred was OK\, even though good old ANSI C allows an implementation to get away with just 37.

DBL_MAX can be found in either float.h or limits.h as here (with a bit of context)​:

  #define FLT_DIG 6 /* Digits of precision of a type * float */   #define DBL_DIG 15 /* Digits of precision of a type * double */   #ifndef __gtab   #define __gtab(x) _Gtab(x)   #ifdef __cplusplus   extern "builtin"   #else   #pragma linkage(_Gtab\, builtin)   #endif   void **_Gtab(int);   #endif   #define __max_flts_i 8   #define __max_flts \   ( *((long double * const) (*(__gtab(__max_flts_i)))) )   #define FLT_MAX ((const float)__max_flts)   #define DBL_MAX ((const double)__max_flts)

DBL_MIN can be found in /usr/include/float.h as​:

  #define DBL_MIN ((const double)__min_flts)

which in turn is​:

  #define __min_flts_i 7   #define __min_flts \   ( *((long double * const) (*(__gtab(__min_flts_i)))) )

I note that the digits\, mantissas\, and exponents specified in float.h are as follows​:

  #define FLT_MANT_DIG 6   #define DBL_MANT_DIG 14   #define LDBL_MANT_DIG 28

  #define FLT_DIG 6   #define DBL_DIG 15   #define LDBL_DIG 32

  #define FLT_MIN_EXP (-64)   #define DBL_MIN_EXP (-64)   #define LDBL_MIN_EXP (-64)

  #define FLT_MIN_10_EXP (-78)   #define DBL_MIN_10_EXP (-78)   #define LDBL_MIN_10_EXP (-78)

  #define FLT_MAX_EXP 63   #define DBL_MAX_EXP 63   #define LDBL_MAX_EXP 63

  #define FLT_MAX_10_EXP 75   #define DBL_MAX_10_EXP 75   #define LDBL_MAX_10_EXP 75

Peter Prymmer

p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

At 15​:31 -0700 2000-10-10\, Peter Prymmer wrote​:

[OS/390 has] #define DBL_MAX_EXP 63 ... #define DBL_MAX_10_EXP 75 [so the tests involving three-digit exponents in op/sprintf.t fail]

OK. Since I think it's worthwhile seeing how three-digit exponents behave on platforms that are supposed to support them\, I propose putting a specific hack into op/sprintf.t such that the affected tests "pass" on OS/390\, but output a comment saying that they were really skipped because of exponent range limitations. This hack may have to be revisited in the event that other hosts with similar limitations pop up in the future. (Anyone know of any? -- I haven't seen a (not )?OK report on Unicos for a while -- possibly because of current compile problems\, but I presume that\, given its application area\, the Cray's native format has a "modern" floating point exponent range. (IEEE format would be OK anyway.))

Is that OK? You'll have to test the thing once I come up with it (sometime in the next week unless you really really really want it sooner)\, as I can't.

p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

"Dominic" == Dominic Dunlop \domo@&#8203;computer\.org writes​:

Anyone know of any? -- I haven't seen a (not)?OK report on Unicos for a while -- possibly because of current compile problems

I didn't send an OK\, since I don't get a clean "make test" due to local setup problems.

but I presume that\, given its application area\, the Cray's native format has a "modern" floating point exponent range. (IEEE format would be OK anyway.))

The man pages claim that all Crays have at least IEEE floating point range.

p5pRT commented 23 years ago

From [Unknown Contact. See original ticket]

On Thu\, 12 Oct 2000\, Dominic Dunlop wrote​:

OK. Since I think it's worthwhile seeing how three-digit exponents behave on platforms that are supposed to support them\, I propose putting a specific hack into op/sprintf.t such that the affected tests "pass" on OS/390\, but output a comment saying that they were really skipped because of exponent range limitations. This hack may have to be revisited in the event that other hosts with similar limitations pop up in the future. (Anyone know of any? -- I haven't seen a (not )?OK report on Unicos for a while -- possibly because of current compile problems\, but I presume that\, given its application area\, the Cray's native format has a "modern" floating point exponent range. (IEEE format would be OK anyway.))

That sounds like a reasonable compromise to me. (It has been many years since I ever used unicos so I'll refrain from commenting on it).

Is that OK? You'll have to test the thing once I come up with it (sometime in the next week unless you really really really want it sooner)\, as I can't.

Excellent. Thank you for your offer (it kind of makes you wish that h2ph had already been run over float.h et al doesn't it?).

Peter Prymmer

p5pRT commented 23 years ago

From [Unknown Contact. See original ticket]

At 08​:49 -0700 2000-10-12\, Prymmer/Kahn wrote​:

Thank you for your offer (it kind of makes you wish that h2ph had already been run over float.h et al doesn't it?).

Indeed it does -- except I just tried h2ph on the excerpts of header files that you sent\, and the (crucial) definition of __max_flts translates into illegal Perl! Other alternatives that I wasn't about to ask for were Configure support so that I could easily determine DBL_MAX and DBL_MIN; or trying to sniff header files at run-time.

p5pRT commented 23 years ago

From [Unknown Contact. See original ticket]

On Thu\, 12 Oct 2000\, Dominic Dunlop wrote​:

At 08​:49 -0700 2000-10-12\, Prymmer/Kahn wrote​:

Thank you for your offer (it kind of makes you wish that h2ph had already been run over float.h et al doesn't it?).

Indeed it does -- except I just tried h2ph on the excerpts of header files that you sent\, and the (crucial) definition of __max_flts translates into illegal Perl! Other alternatives that I wasn't about to ask for were Configure support so that I could easily determine DBL_MAX and DBL_MIN; or trying to sniff header files at run-time.

Yes it does look like OS/390's float.ph is a dud coming fresh off the h2ph assembly line​:

$ perl -w -Mwarnings -e 'require "float.ph"' Syntax error at /tmp/pinst/lib/perl5/site_perl/5.7.0/os390/float.ph line 35\, near "\;" Syntax error at /tmp/pinst/lib/perl5/site_perl/5.7.0/os390/float.ph line 38\, near "\;" Syntax error at /tmp/pinst/lib/perl5/site_perl/5.7.0/os390/float.ph line 41\, near "\;" Syntax error at /tmp/pinst/lib/perl5/site_perl/5.7.0/os390/float.ph line 44\, near "\;" Syntax error at /tmp/pinst/lib/perl5/site_perl/5.7.0/os390/float.ph line 47\, near "\;" Unmatched right curly bracket at /tmp/pinst/lib/perl5/site_perl/5.7.0/os390/float.ph line 140\, at end of line Syntax error at /tmp/pinst/lib/perl5/site_perl/5.7.0/os390/float.ph line 140\, near "}" Compilation failed in require at -e line 1.

Among the strategies that you mention a Configure probe -> config.sh variable sounds the safest to me. A problem with h2ph is that it tends not to check itself with evals of its generated code hence .ph files often need to be hand tweaked (not to mention that at `make test` time h2ph has not been run and running it is not a Makefile target).

Problems with the runtime check include figuring out the correct path to the compiler's headers. Note that not all platforms have loose header "files"​: VMS e.g. has them tucked into text libraries (think ar archive but for text) and even OS/390 can have C headers tucked into partitioned data sets or PDSes that are not visible to perl's stdio file handling routines (hence they can\, and do\, get missed by h2ph and the `perl Makefile.PL` process).

Peter Prymmer

p5pRT commented 23 years ago

From @jhi

Which of the several recent please-do-not-apply patches of yours should I\, errrm\, apply? Some\, some parts of\, none? Or should Simon first Fix UTF8-on-EBCDIC?

p5pRT commented 23 years ago

From [Unknown Contact. See original ticket]

On Thu\, 12 Oct 2000\, Jarkko Hietaniemi wrote​:

Which of the several recent please-do-not-apply patches of yours should I\, errrm\, apply? Some\, some parts of\, none? Or should Simon first Fix UTF8-on-EBCDIC?

I think there was only one diff that was sent to p5p that Simon objected to on the grounds that it merely circumvented trouble with C\<use utf8;> in scope by avoiding it altogether on EBCDIC platforms. That would be the message in​:

http​://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-10/msg00492.html

Message-ID​: \Pine\.OSF\.4\.10\.10010111740200\.516446\-100000@&#8203;aspara\.forte\.com

you'll note that the subject header for that message did not have /\[PATCH/ in it.

I also posted a diff to perl-mvs only (not p5p) that correctly treats the chr(92) problem for op/regmesg.t\, but also skips the two utf8 tests in that file hence it would be unacceptable to Simon. It too did not have a /\[PATCH/ subject line and neither of those diffs were acknowledged by you.

As Simon points out the real fix is to massage the utf8 pragma to not barf on EBCDIC input rather than cutting it out of a lot of tests.

AFAIK you have not indicated applying any of the potentially controversial "avoid utf8" patches with the possible exception of the op/tr.t one. As I mentioned I tested that on OSF and it passed with or without the C\<use utf8;> statement in the scope of the tests at the lower portion of the file. I'll issue a reversal of that one if you'd like.

BTW\, sorry for being so grumpy\, I was suffering from another "bad 8 bit char" day recently.

Peter Prymmer

p5pRT commented 23 years ago

From @jhi

I'll re-go through your latest patches (the tr.t one v2 and ver.t one have been applied).

AFAIK you have not indicated applying any of the potentially controversial

Have mercy on a man with too many emails to read and a real daytime job :-)

"avoid utf8" patches with the possible exception of the op/tr.t one. As I mentioned I tested that on OSF and it passed with or without the C\<use utf8;> statement in the scope of the tests at the lower portion of the file. I'll issue a reversal of that one if you'd like.

p5pRT commented 23 years ago

From [Unknown Contact. See original ticket]

On Thu\, 12 Oct 2000\, Jarkko Hietaniemi wrote​:

I'll re-go through your latest patches (the tr.t one v2 and ver.t one have been applied).

Thanks.

AFAIK you have not indicated applying any of the potentially controversial

Have mercy on a man with too many emails to read and a real daytime job :-)

OK I hear you (loud and clear). If necessary I'll try to restrict it to *only* coded character set misfeatures (although I too am now suffering from a sever tuit deficit).

Peter Prymmer

p5pRT commented 23 years ago

From @jhi

On Thu\, Oct 12\, 2000 at 06​:39​:25PM -0700\, Peter Prymmer wrote​:

On Thu\, 12 Oct 2000\, Jarkko Hietaniemi wrote​:

I'll re-go through your latest patches (the tr.t one v2 and ver.t one have been applied).

Thanks.

Now also the oct.t one\, as patch 7212.

p5pRT commented 23 years ago

From [Unknown Contact. See original ticket]

Here's a patch which should make OS/390 (and any other host with limited floating-point exponent length) pass (or appear to pass) the tests in op/sprintf.t. Could you try it please. In particular\, run it like

cd t; ./perl op/sprintf.t

and check that you see lines such as

ok 12 >%G\< >.1234567e-101\< >0\< # Suppressed​: exponent out of range?

Beware slightly long lines.

Inline Patch ```diff --- perl@7211/t/op/sprintf.t-as-received Fri Sep 15 02:55:13 2000 +++ perl@7211/t/op/sprintf.t Fri Oct 13 19:07:01 2000 @@ -56,8 +56,17 @@ } elsif ($y eq ">$result<") # Some C libraries always give { # three-digit exponent - print("ok $i >$result< $x # three-digit exponent accepted\n"); + print("ok $i >$result< $x # three-digit exponent accepted\n"); } + elsif ($result =~ /[-+]\d{3}$/ && + # Suppress tests with modulo of exponent >= 100 on platforms + # which can't handle such magnitudes (or where we can't tell). + ((!eval {require POSIX}) || # Costly: only do this if we must! + (length(&POSIX::DBL_MAX) - rindex(&POSIX::DBL_MAX, '+')) == 3)) + { + print("ok $i >$template< >$data< >$result<", + " # Suppressed: exponent out of range?\n") + } else { $y = ($x eq $y ? "" : " => $y"); print("not ok $i >$template< >$data< >$result< $x$y", ```
p5pRT commented 23 years ago

From [Unknown Contact. See original ticket]

On Fri\, 13 Oct 2000\, Dominic Dunlop wrote​:

Here's a patch which should make OS/390 (and any other host with limited floating-point exponent length) pass (or appear to pass) the tests in op/sprintf.t. Could you try it please. In particular\, run it like

cd t; ./perl op/sprintf.t

and check that you see lines such as

ok 12 >%G\< >.1234567e-101\< >0\< # Suppressed​: exponent out of range?

Beware slightly long lines.

It seemed to apply cleanly for me. Unfortunately during `make test` I still saw​:

op/sprintf...........FAILED at test 11

and running it by hand I see these unusual spots​:

ok 11 >%G\< >1234567e96\< >1.23457E+102\< # Suppressed​: exponent out of range? ok 12 >%G\< >.1234567e-101\< >1.23457E-102\< # Suppressed​: exponent out of range?

ok 90 >%e\< >1234567E96\< >1.234567e+102\< # Suppressed​: exponent out of range?

ok 92 >%e\< >.1234567E-101\< >1.234567e-102\< # Suppressed​: exponent out of range?

ok 156 >%g\< >1234567E96\< >1.23457e+102\< # Suppressed​: exponent out of range? ok 157 >%g\< >.1234567E-101\< >1.23457e-102\< # Suppressed​: exponent out of range?

So the only "problem" now appears to be the placement of the octothorpes. The following patch can go over the one that Dominic posted and with it `make test` reports​:

op/sprintf...........ok

and the extra lines seen by running the test by hand appear as​:

ok 11 # >%G\< >1234567e96\< >1.23457E+102\< Suppressed​: exponent out of range? ok 12 # >%G\< >.1234567e-101\< >1.23457E-102\< Suppressed​: exponent out of range?

ok 90 # >%e\< >1234567E96\< >1.234567e+102\< Suppressed​: exponent out of range?

ok 92 # >%e\< >.1234567E-101\< >1.234567e-102\< Suppressed​: exponent out of range?

ok 156 # >%g\< >1234567E96\< >1.23457e+102\< Suppressed​: exponent out of range? ok 157 # >%g\< >.1234567E-101\< >1.23457e-102\< Suppressed​: exponent out of range?

Here is the patch to your patch​:

Inline Patch ```diff --- t/op/sprintf.t.as.patched Fri Oct 13 14:15:08 2000 +++ t/op/sprintf.t Fri Oct 13 14:17:24 2000 @@ -56,7 +56,7 @@ } elsif ($y eq ">$result<") # Some C libraries always give { # three-digit exponent - print("ok $i >$result< $x # three-digit exponent accepted\n"); + print("ok $i # >$result< $x three-digit exponent accepted\n"); } elsif ($result =~ /[-+]\d{3}$/ && # Suppress tests with modulo of exponent >= 100 on platforms @@ -64,8 +64,8 @@ ((!eval {require POSIX}) || # Costly: only do this if we must! (length(&POSIX::DBL_MAX) - rindex(&POSIX::DBL_MAX, '+')) == 3)) { - print("ok $i >$template< >$data< >$result<", - " # Suppressed: exponent out of range?\n") + print("ok $i # >$template< >$data< >$result<", + " Suppressed: exponent out of range?\n") } else { $y = ($x eq $y ? "" : " => $y"); ```

End of Patch to Patch.

Thanks Dominic!

Peter Prymmer

p5pRT commented 23 years ago

From [Unknown Contact. See original ticket]

At 15​:31 -0700 2000-10-10\, Peter Prymmer wrote​:

[OS/390 has] #define DBL_MAX_EXP 63 ... #define DBL_MAX_10_EXP 75 [so the tests involving three-digit exponents in op/sprintf.t fail]

OK. Since I think it's worthwhile seeing how three-digit exponents behave on platforms that are supposed to support them\, I propose putting a specific hack into op/sprintf.t such that the affected tests "pass" on OS/390\, but output a comment saying that they were really skipped because of exponent range limitations.

Don't forget that the IBM 360 and successors use base 16 instead of base 2 for floating point. That is\, instead of   number = fraction * 2 ** exponent it uses   number = fraction * 16 ** exponent such that bumping the LSB causes a larger jump than with other FPUs.

  unix% perl -le 'print 16**63'   7.23700557733226e+75

The biggest base 16 exponent is 63 (equals 2**252) for a decimal exponent of 75.

  -Joe

P.S. The last time I used that piece of knowledge was June\, 1978.

p5pRT commented 20 years ago

From The RT System itself

most of the bugs listed here have been fixed by now by various patches\, time for a new report from EBCDIC.