Perl / perl5

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

infinity is formatted with leading spaces e.g. " Inf" #6745

Closed p5pRT closed 4 years ago

p5pRT commented 20 years ago

Migrated from rt.perl.org#23731 (status was 'open')

Searchable as RT23731$

p5pRT commented 20 years ago

From david.dyck@fluke.com

Created by david.dyck@fluke.com

I tried to use CPAN's Set​::Infinite\, which seems to care about the string representation of infinity.

On my computer perl reports

perl -wle 'print q(").(100**100**100).q(")' " Inf"

It's my guess that this may be a libc5 issue\, but does perl have a standard way that it proposed to export the infinity string to it's client scripts?

My old perl3 and perl4 binaries also print the same string for infinity as perl5.9.0.

The following test program in C doesn't display the leading spaces\, why does perl?

  int main() {   long linf = 0x7f800000;   printf( "\<%g>\n"\, *(float*) &linf);   return 0;   }

which prints \

Perl Info ``` Flags: category=core severity=medium Site configuration information for perl v5.9.0: Configured by dcd at Thu Sep 4 15:03:57 PDT 2003. Summary of my perl5 (revision 5.0 version 9 subversion 0 patch 21036) configuration: Platform: osname=linux, osvers=2.4.23pre1, archname=i686-linux uname='linux dd 2.4.23pre1 #2 wed aug 27 11:20:37 pdt 2003 i686 ' config_args='-Dmksymlinks -Dinstallusrbinperl -Uversiononly -Dusedevel -Doptimize=-O3 -g -de -Dcf_email=david.dyck@fluke.com' hint=recommended, useposix=true, d_sigaction=define usethreads=undef useithreads=undef usemultiplicity=undef useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-DDEBUGGING -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O3 -g', cppflags='-DDEBUGGING -fno-strict-aliasing -I/usr/local/include' ccversion='', gccversion='egcs-2.91.66.1 19990314/Linux (egcs-1.1.2 release)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=4 alignbytes=4, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lgdbm -ldbm -ldb -ldl -lm -lc perllibs=-ldl -lm -lc libc=/lib/libc.so.5.4.44, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic' cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib' Locally applied patches: DEVEL20173 @INC for perl v5.9.0: /usr/local/lib/perl5/5.9.0/i686-linux /usr/local/lib/perl5/5.9.0 /usr/local/lib/perl5/site_perl/5.9.0/i686-linux /usr/local/lib/perl5/site_perl/5.9.0 /usr/local/lib/perl5/site_perl/5.8.0/i686-linux /usr/local/lib/perl5/site_perl/5.8.0 /usr/local/lib/perl5/site_perl . Environment for perl v5.9.0: HOME=/home/dcd LANG (unset) LANGUAGE (unset) LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=/home/dcd/bin:/sbin:/usr/local/bin:/bin:/usr/bin:/usr/X11/bin:/usr/games:/usr/local/samba:/home/hobbes/tools/scripts:/home/hobbes/tools/linux:/usr0/hobbes/tools/scripts:/usr0/dcd/bin:/apps/general/bin:/usr/public PERL5_CPANPLUS_CONFIG=/home/dcd/.cpanplus/config PERL_BADLANG (unset) SHELL=/bin/bash ```
p5pRT commented 20 years ago

From enache@rdslink.ro

On Fri\, Sep 05\, 2003 a.d.\, David Dyck wrote​:

On my computer perl reports

perl -wle 'print q(").(100**100**100).q(")' " Inf"

It's my guess that this may be a libc5 issue\, but does perl have a standard way that it proposed to export the infinity string to it's client scripts?

what does your perl say for​:

$ perl -MConfig -le 'print $Config{d_Gconvert}'

?

Regards\, Adi

p5pRT commented 20 years ago

From @ysth

On Fri\, Sep 05\, 2003 at 12​:46​:28AM -0000\, David Dyck \perlbug\-followup@&#8203;perl\.org wrote​:

I tried to use CPAN's Set​::Infinite\, which seems to care about the string representation of infinity.

On my computer perl reports

perl -wle 'print q(").(100**100**100).q(")' " Inf"

It's my guess that this may be a libc5 issue\, but does perl have a standard way that it proposed to export the infinity string to it's client scripts?

Try configuring with -Dd_Gconvert='sprintf((b)\,"%.*g"\,(n)\,(x))\,strcpy((b)\,strtok((b)\," "))'

(Is strcpy guaranteed to work with overlapping strings?)

My old perl3 and perl4 binaries also print the same string for infinity as perl5.9.0.

The following test program in C doesn't display the leading spaces\, why does perl?

int main\(\) \{
long linf = 0x7f800000;
printf\( "\<%g>\\n"\, \*\(float\*\) &linf\);
return 0;
\}

which prints \

Perhaps the libc bug is only triggered when a precision is given\, e.g. printf("%.15g"\,inf)\, or (as perl does it)\, sprintf(buf\, "%.*g"\, DBL_DIG\, inf)

p5pRT commented 20 years ago

From david.dyck@fluke.com

On Fri\, 5 Sep 2003 at 17​:09 -0000\, Adrian Enache \<perlbug-followup@​perl.org...​:

From​: Adrian Enache \perlbug\-followup@&#8203;perl\.org To​: david.dyck@​fluke.com Date​: 5 Sep 2003 17​:09​:01 -0000 Subject​: Re​: [perl #23731] infinity is formatted with leading spaces e.g. " Inf"

On Fri\, Sep 05\, 2003 a.d.\, David Dyck wrote​:

On my computer perl reports

perl -wle 'print q(").(100**100**100).q(")' " Inf"

It's my guess that this may be a libc5 issue\, but does perl have a standard way that it proposed to export the infinity string to it's client scripts?

what does your perl say for​:

$ perl -MConfig -le 'print $Config{d_Gconvert}'

?

$ perl -MConfig -le 'print $Config{d_Gconvert}' sprintf((b)\,"%.*g"\,(n)\,(x))

I guess to get the leading spaces that print uses I'd need to used %.15g like this​:

$ perl -wle 'printf q(")."%15g".qq("\n)\, (100**100**100)' " Inf"

p5pRT commented 20 years ago

From enache@rdslink.ro

On Fri\, Sep 05\, 2003 a.d.\, Yitzchak Scott-Thoennes wrote​:

Try configuring with -Dd_Gconvert='sprintf((b)\,"%.*g"\,(n)\,(x))\,strcpy((b)\,strtok((b)\," "))'   ^^^^^^

(Is strcpy guaranteed to work with overlapping strings?)

From the linux strtok manpage​:

BUGS   Never use these functions. If you do\, note that​:

  These functions modify their first argument.

  These functions cannot be used on constant strings.

  The identity of the delimiting character is lost.

  The strtok() function uses a static buffer while parsing\, so   it's not thread safe. Use strtok_r() if this matters to you.

Regards\, Adi

p5pRT commented 20 years ago

From enache@rdslink.ro

On Fri\, Sep 05\, 2003 a.d.\, Yitzchak Scott-Thoennes wrote​:

(Is strcpy guaranteed to work with overlapping strings?)

No\, it's not.

p5pRT commented 20 years ago

From enache@rdslink.ro

On Fri\, Sep 05\, 2003 a.d.\, David Dyck wrote​:

$ perl -MConfig -le 'print $Config{d_Gconvert}' sprintf((b)\,"%.*g"\,(n)\,(x))

You could try a small C program to see if

sprintf((b)\,"%-.*g"\,(n)\,(x))

is triggering the same bug.

Regards\, Adi

p5pRT commented 20 years ago

From david.dyck@fluke.com

On Fri\, 5 Sep 2003 at 22​:28 +0300\, Enache Adrian \enache@&#8203;rdslink\.ro wrote​:

On Fri\, Sep 05\, 2003 a.d.\, David Dyck wrote​:

$ perl -MConfig -le 'print $Config{d_Gconvert}' sprintf((b)\,"%.*g"\,(n)\,(x))

You could try a small C program to see if

sprintf((b)\,"%-.*g"\,(n)\,(x))

is triggering the same bug.

Not quite the same

For which values of n above?

int main() {   long linf = 0x7f800000;   float x = *(float*) &linf; #if 0   printf( "\<%g>\n"\, *(float*) &linf); #endif

  char b[128];   int n=0;   for (n=-15; n\<=15; n++) {   sprintf((b)\,"%-.*g"\,(n)\,(x));   printf("n=%-3d \<%s>\n"\, n\, b);   }

  return 0; }

n=-15 \ n=-14 \ n=-13 \ n=-12 \ n=-11 \ n=-10 \ n=-9 \ n=-8 \ n=-7 \ n=-6 \ n=-5 \ n=-4 \ n=-3 \ n=-2 \ n=-1 \ n=0 \ n=1 \ n=2 \ n=3 \ n=4 \ n=5 \ n=6 \ n=7 \ n=8 \ n=9 \ n=10 \ n=11 \ n=12 \ n=13 \ n=14 \ n=15 \

p5pRT commented 20 years ago

From @mjdominus

Enache Adrian \enache@&#8203;rdslink\.ro​:

On Fri\, Sep 05\, 2003 a.d.\, Yitzchak Scott-Thoennes wrote​:

Try configuring with -Dd_Gconvert='sprintf((b)\,"%.*g"\,(n)\,(x))\,strcpy((b)\,strtok((b)\," "))' ^^^^^^

(Is strcpy guaranteed to work with overlapping strings?)

From the linux strtok manpage​:

BUGS Never use these functions. If you do\, note that​:

          These functions modify their first argument\.
          These functions cannot be used on constant strings\.
          The identity of the delimiting character is lost\.
          The strtok\(\) function uses a static  buffer  while  parsing\,  so
          it's not thread safe\. Use strtok\_r\(\) if this matters to you\.

strtok() is a red herring; he should be using strchr() for that.

However\, strcpy() is *not* guaranteed to work on overlapping buffers; its behavior is undefined in that case.

p5pRT commented 20 years ago

From @ysth

On Fri\, Sep 05\, 2003 at 05​:52​:44PM -0400\, Mark Jason Dominus \mjd@&#8203;plover\.com wrote​:

Enache Adrian \enache@&#8203;rdslink\.ro​:

On Fri\, Sep 05\, 2003 a.d.\, Yitzchak Scott-Thoennes wrote​:

Try configuring with -Dd_Gconvert='sprintf((b)\,"%.*g"\,(n)\,(x))\,strcpy((b)\,strtok((b)\," "))' ^^^^^^

(Is strcpy guaranteed to work with overlapping strings?)

From the linux strtok manpage​:

BUGS Never use these functions. If you do\, note that​:

          These functions modify their first argument\.
          These functions cannot be used on constant strings\.
          The identity of the delimiting character is lost\.
          The strtok\(\) function uses a static  buffer  while  parsing\,  so
          it's not thread safe\. Use strtok\_r\(\) if this matters to you\.

strtok() is a red herring; he should be using strchr() for that.

Umm\, no. strtok is what I want. And those "bugs" are exactly what strtok is supposed to do. You could come up with something using strcspn\, though.

However\, strcpy() is *not* guaranteed to work on overlapping buffers; its behavior is undefined in that case.

Given that perl is always going to pass a 64 or 20+NV_DIG byte buffer\, you could use memmove. But I think that strcpy will actually be just fine\, given that it will be either copying a string onto itself or copying from (b)+12 to (b). I think documentation of undefined behaviour is just to allow it to blindly copy even when going to a greater memory address or copying more than one byte at a time (but I doubt there are implementations that copy in 12 or more byte chunks).

In any case\, this isn't how I would propose a change to configure\, just a workaround that will probably work in this one circumstance.

p5pRT commented 20 years ago

From @ysth

On Fri\, Sep 05\, 2003 at 02​:21​:54PM -0700\, David Dyck \david\.dyck@&#8203;fluke\.com wrote​:

On Fri\, 5 Sep 2003 at 22​:28 +0300\, Enache Adrian \enache@&#8203;rdslink\.ro wrote​:

sprintf((b)\,"%.*g"\,(n)\,(x))

You could try a small C program to see if

sprintf((b)\,"%-.*g"\,(n)\,(x))

is triggering the same bug.

Not quite the same

For which values of n above?

Look at perl.h for DBL_DIG and you will see a humongous block of code that almost always comes up with 15 for (n).

p5pRT commented 20 years ago

From david.dyck@fluke.com

On Fri\, 5 Sep 2003 at 18​:17 -0000\, Yitzchak Scott-Thoennes \<perlbug-followu...​:

On Fri\, Sep 05\, 2003 at 12​:46​:28AM -0000\, David Dyck \perlbug\-followup@&#8203;perl\.org wrote​:

I tried to use CPAN's Set​::Infinite\, which seems to care about the string representation of infinity.

On my computer perl reports

perl -wle 'print q(").(100**100**100).q(")' " Inf"

Try configuring with -Dd_Gconvert='sprintf((b)\,"%.*g"\,(n)\,(x))\,strcpy((b)\,strtok((b)\," "))'

I tried this and got All tests successful. (not multi-threaded) Perhaps there are no test cases that exersize the problems with strcpy and strtok mentioned in other emails.

The new perl reports $ ./perl -wle 'print q(").(100**100**100).q(")' "Inf"

(Is strcpy guaranteed to work with overlapping strings?)

Perhaps the libc bug is only triggered when a precision is given\, e.g. printf("%.15g"\,inf)\, or (as perl does it)\, sprintf(buf\, "%.*g"\, DBL_DIG\, inf)

  sprintf(buf\, "%.*g"\, DBL_DIG\, inf);   printf("DBL_DIG=%-3d \<%s>\n"\, DBL_DIG\, buf); reports DBL_DIG=15 \< Inf>

p5pRT commented 20 years ago

From david.dyck@fluke.com

On Fri\, 5 Sep 2003 at 23​:02 -0000\, Yitzchak Scott-Thoennes \<perlbug-followu...​:

From​: Yitzchak Scott-Thoennes \perlbug\-followup@&#8203;perl\.org

On Fri\, Sep 05\, 2003 at 02​:21​:54PM -0700\, David Dyck \david\.dyck@&#8203;fluke\.com wrote​:

On Fri\, 5 Sep 2003 at 22​:28 +0300\, Enache Adrian \enache@&#8203;rdslink\.ro wrote​:

sprintf((b)\,"%.*g"\,(n)\,(x))

You could try a small C program to see if

sprintf((b)\,"%-.*g"\,(n)\,(x))

is triggering the same bug.

Not quite the same

For which values of n above?

Look at perl.h for DBL_DIG and you will see a humongous block of code that almost always comes up with 15 for (n).

Yes\, I see it. $ perl -lMPOSIX=DBL_DIG -e 'print DBL_DIG' 15

p5pRT commented 18 years ago

From david.dyck@fluke.com

[dcd - Thu Sep 04 17​:46​:28 2003]​: I tried to use CPAN's Set​::Infinite\, which seems to care about the string representation of infinity.

Just to follow up - I don't get the test failures from Set​::Infinite any more\, as they worked around it 0.5306   fix bug in test "inf" -> "$inf". Thanks Kingpin

Will perl get test cases or will it remain platform dependent?

p5pRT commented 18 years ago

From @smpeters

[dcd - Fri Oct 07 14​:22​:14 2005]​:

[dcd - Thu Sep 04 17​:46​:28 2003]​: I tried to use CPAN's Set​::Infinite\, which seems to care about the string representation of infinity.

Just to follow up - I don't get the test failures from Set​::Infinite any more\, as they worked around it 0.5306 fix bug in test "inf" -> "$inf". Thanks Kingpin

Will perl get test cases or will it remain platform dependent?

Are you still getting the odd results with

perl -wle 'print q(").(100**100**100).q(")' " Inf"

If so\, may I ask what Linux you are running?

p5pRT commented 18 years ago

From david.dyck@fluke.com

On Wed\, 10 May 2006 at 18​:08 -0700\, Steve Peters via RT \<perlbug-followup@​p...​:

From​: Steve Peters via RT \perlbug\-followup@&#8203;perl\.org To​: "Dyck\, David" \david\.dyck@&#8203;fluke\.com Date​: Wed\, 10 May 2006 18​:08​:02 -0700 Subject​: [perl #23731] infinity is formatted with leading spaces e.g. " Inf"

[dcd - Fri Oct 07 14​:22​:14 2005]​:

[dcd - Thu Sep 04 17​:46​:28 2003]​: I tried to use CPAN's Set​::Infinite\, which seems to care about the string representation of infinity.

Just to follow up - I don't get the test failures from Set​::Infinite any more\, as they worked around it 0.5306 fix bug in test "inf" -> "$inf". Thanks Kingpin

Will perl get test cases or will it remain platform dependent?

Are you still getting the odd results with

perl -wle 'print q(").(100**100**100).q(")' " Inf"

If so\, may I ask what Linux you are running?

This is what I get today

dd​:dcd$ perl -wle 'print q(").(100**100**100).q(")' " Inf"

Linux dd 2.4.33-pre3 #1 Mon May 1 07​:22​:46 PDT 2006 i686

as you can see\, my libc is 'older' :-)   libdl.so.1 => /lib/libdl.so.1 (0x4000d000)   libm.so.5 => /lib/libm.so.5 (0x40010000)   libc.so.5 => /lib/libc.so.5 (0x40019000)

dd​:dcd$ ls -l /lib/libc.so.5 lrwxrwxrwx 1 root root 14 May 13 1998 /lib/libc.so.5 -> libc.so.5.4.44*

dd​:dcd$ ls -lL /lib/libc.so.5 -rwxr-xr-x 1 bin bin 1874736 Feb 1 1998 /lib/libc.so.5*

p5pRT commented 18 years ago

From @ysth

On Wed\, May 10\, 2006 at 06​:41​:31PM -0700\, David Dyck wrote​:

On Wed\, 10 May 2006 at 18​:08 -0700\, Steve Peters via RT \<perlbug-followup@​p...​:

From​: Steve Peters via RT \perlbug\-followup@&#8203;perl\.org To​: "Dyck\, David" \david\.dyck@&#8203;fluke\.com Date​: Wed\, 10 May 2006 18​:08​:02 -0700 Subject​: [perl #23731] infinity is formatted with leading spaces e.g. " Inf"

[dcd - Fri Oct 07 14​:22​:14 2005]​:

[dcd - Thu Sep 04 17​:46​:28 2003]​: I tried to use CPAN's Set​::Infinite\, which seems to care about the string representation of infinity.

Just to follow up - I don't get the test failures from Set​::Infinite any more\, as they worked around it 0.5306 fix bug in test "inf" -> "$inf". Thanks Kingpin

Will perl get test cases or will it remain platform dependent?

Are you still getting the odd results with

perl -wle 'print q(").(100**100**100).q(")' " Inf"

If so\, may I ask what Linux you are running?

This is what I get today

dd​:dcd$ perl -wle 'print q(").(100**100**100).q(")' " Inf"

Linux dd 2.4.33-pre3 #1 Mon May 1 07​:22​:46 PDT 2006 i686

as you can see\, my libc is 'older' :-) libdl.so.1 => /lib/libdl.so.1 (0x4000d000) libm.so.5 => /lib/libm.so.5 (0x40010000) libc.so.5 => /lib/libc.so.5 (0x40019000)

dd​:dcd$ ls -l /lib/libc.so.5 lrwxrwxrwx 1 root root 14 May 13 1998 /lib/libc.so.5 -> libc.so.5.4.44*

dd​:dcd$ ls -lL /lib/libc.so.5 -rwxr-xr-x 1 bin bin 1874736 Feb 1 1998 /lib/libc.so.5*

I remember someone reporting this before with an old libc.

They got it working with an evil hack involving setting d_Gconvert to an expression including strtok.

p5pRT commented 18 years ago

From @smpeters

On Wed\, May 10\, 2006 at 06​:59​:29PM -0700\, Yitzchak Scott-Thoennes wrote​:

On Wed\, May 10\, 2006 at 06​:41​:31PM -0700\, David Dyck wrote​:

On Wed\, 10 May 2006 at 18​:08 -0700\, Steve Peters via RT \<perlbug-followup@​p...​:

From​: Steve Peters via RT \perlbug\-followup@&#8203;perl\.org To​: "Dyck\, David" \david\.dyck@&#8203;fluke\.com Date​: Wed\, 10 May 2006 18​:08​:02 -0700 Subject​: [perl #23731] infinity is formatted with leading spaces e.g. " Inf"

[dcd - Fri Oct 07 14​:22​:14 2005]​:

[dcd - Thu Sep 04 17​:46​:28 2003]​: I tried to use CPAN's Set​::Infinite\, which seems to care about the string representation of infinity.

Just to follow up - I don't get the test failures from Set​::Infinite any more\, as they worked around it 0.5306 fix bug in test "inf" -> "$inf". Thanks Kingpin

Will perl get test cases or will it remain platform dependent?

Are you still getting the odd results with

perl -wle 'print q(").(100**100**100).q(")' " Inf"

If so\, may I ask what Linux you are running?

This is what I get today

dd​:dcd$ perl -wle 'print q(").(100**100**100).q(")' " Inf"

Linux dd 2.4.33-pre3 #1 Mon May 1 07​:22​:46 PDT 2006 i686

as you can see\, my libc is 'older' :-) libdl.so.1 => /lib/libdl.so.1 (0x4000d000) libm.so.5 => /lib/libm.so.5 (0x40010000) libc.so.5 => /lib/libc.so.5 (0x40019000)

dd​:dcd$ ls -l /lib/libc.so.5 lrwxrwxrwx 1 root root 14 May 13 1998 /lib/libc.so.5 -> libc.so.5.4.44*

dd​:dcd$ ls -lL /lib/libc.so.5 -rwxr-xr-x 1 bin bin 1874736 Feb 1 1998 /lib/libc.so.5*

I remember someone reporting this before with an old libc.

They got it working with an evil hack involving setting d_Gconvert to an expression including strtok.

This would be that ticket :). Just making sure there is a vicitm^Wtester still available to work with :)

Steve Peters steve@​fisharerojo.org

p5pRT commented 10 years ago

From @Hugmeir

On Thu Sep 04 17​:46​:28 2003\, dcd wrote​:

This is a bug report for perl from david.dyck@​fluke.com\, generated with the help of perlbug 1.34 running under perl v5.9.0.

----------------------------------------------------------------- [Please enter your report here]

I tried to use CPAN's Set​::Infinite\, which seems to care about the string representation of infinity.

On my computer perl reports

perl -wle 'print q(").(100**100**100).q(")' " Inf"

It's my guess that this may be a libc5 issue\, but does perl have a standard way that it proposed to export the infinity string to it's client scripts?

My old perl3 and perl4 binaries also print the same string for infinity as perl5.9.0.

The following test program in C doesn't display the leading spaces\, why does perl?

int main\(\) \{
long linf = 0x7f800000;
printf\( "\<%g>\\n"\, \*\(float\*\) &linf\);
return 0;
\}

which prints \

[Please do not change anything below this line] ----------------------------------------------------------------- --- Flags​: category=core severity=medium --- Site configuration information for perl v5.9.0​:

Configured by dcd at Thu Sep 4 15​:03​:57 PDT 2003.

Summary of my perl5 (revision 5.0 version 9 subversion 0 patch 21036) configuration​: Platform​: osname=linux\, osvers=2.4.23pre1\, archname=i686-linux uname='linux dd 2.4.23pre1 #2 wed aug 27 11​:20​:37 pdt 2003 i686 ' config_args='-Dmksymlinks -Dinstallusrbinperl -Uversiononly -Dusedevel -Doptimize=-O3 -g -de -Dcf_email=david.dyck@​fluke.com' hint=recommended\, useposix=true\, d_sigaction=define usethreads=undef useithreads=undef usemultiplicity=undef useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n\, bincompat5005=undef Compiler​: cc='cc'\, ccflags ='-DDEBUGGING -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64'\, optimize='-O3 -g'\, cppflags='-DDEBUGGING -fno-strict-aliasing -I/usr/local/include' ccversion=''\, gccversion='egcs-2.91.66.1 19990314/Linux (egcs- 1.1.2 release)'\, gccosandvers='' intsize=4\, longsize=4\, ptrsize=4\, doublesize=8\, byteorder=1234 d_longlong=define\, longlongsize=8\, d_longdbl=define\, longdblsize=12 ivtype='long'\, ivsize=4\, nvtype='double'\, nvsize=8\, Off_t='off_t'\, lseeksize=4 alignbytes=4\, prototype=define Linker and Libraries​: ld='cc'\, ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lgdbm -ldbm -ldb -ldl -lm -lc perllibs=-ldl -lm -lc libc=/lib/libc.so.5.4.44\, so=so\, useshrplib=false\, libperl=libperl.a gnulibc_version='' Dynamic Linking​: dlsrc=dl_dlopen.xs\, dlext=so\, d_dlsymun=undef\, ccdlflags='- rdynamic' cccdlflags='-fpic'\, lddlflags='-shared -L/usr/local/lib'

Locally applied patches​: DEVEL20173

--- @​INC for perl v5.9.0​: /usr/local/lib/perl5/5.9.0/i686-linux /usr/local/lib/perl5/5.9.0 /usr/local/lib/perl5/site_perl/5.9.0/i686-linux /usr/local/lib/perl5/site_perl/5.9.0 /usr/local/lib/perl5/site_perl/5.8.0/i686-linux /usr/local/lib/perl5/site_perl/5.8.0 /usr/local/lib/perl5/site_perl .

--- Environment for perl v5.9.0​: HOME=/home/dcd LANG (unset) LANGUAGE (unset) LD_LIBRARY_PATH (unset) LOGDIR (unset)

PATH=/home/dcd/bin​:/sbin​:/usr/local/bin​:/bin​:/usr/bin​:/usr/X11/bin​:/usr/games​:/usr/local/samba​:/home/hobbes/tools/scripts​:/home/hobbes/tools/linux​:/usr0/hobbes/tools/scripts​:/usr0/dcd/bin​:/apps/general/bin​:/usr/public PERL5_CPANPLUS_CONFIG=/home/dcd/.cpanplus/config PERL_BADLANG (unset) SHELL=/bin/bash

This bug report hasn't seen any activity in seven years. I can't reproduce the leading spaces on any OS that I have at hand*\, and the value of d_Gconvert looks drastically different too. Short of someone being able to reproduce this\, can we close the ticket?

[*] Ubuntu 11.04 & 13.04​: "inf"

Archlinux​: "inf"

Debian wheezy​: "inf"

CentOS 5.6 & 6​: "inf"

OpenSUSE​: "inf"

Gentoo​: "inf"

Android 4.0.4​: "Inf"

Mac OS X 10.8.4​: "inf"

QNX Neutrino​: "inf"

Windows Server 2008​: "1.#INF"

Windows Server 2008\, cygwin​: "inf"

Syllable​: "inf"

Haiku​: "inf"

Solaris 11​: "Infinity"

OmniOS​: "Infinity"

FreeBSD 9.0​: "inf"

NetBSD 5.1.2​: "inf"

OpenBSD 5.0​: "inf"

--hugmeir

p5pRT commented 10 years ago

From @epa

I suggest the general issue is not the leading spaces but that infinity stringifies differently on different platforms\, making it difficult for Perl code which looks at that string representation.

It would certainly be worthwhile to make Perl return a single string such as 'Inf' no matter what the platform. That would squash this bug and all future bugs of the same kind.

p5pRT commented 10 years ago

From @doughera88

On Wed\, Aug 07\, 2013 at 06​:59​:03AM -0700\, "Ed Avis via RT" wrote​:

I suggest the general issue is not the leading spaces but that infinity stringifies differently on different platforms\, making it difficult for Perl code which looks at that string representation.

It would certainly be worthwhile to make Perl return a single string such as 'Inf' no matter what the platform. That would squash this bug and all future bugs of the same kind.

But it would introduce new issues where the result on a single platform depended on the language used to generate that result. At various times with various projects\, I have wanted it both ways. I don't have any easy answer.

--   Andy Dougherty doughera@​lafayette.edu

p5pRT commented 10 years ago

From zefram@fysh.org

Andy Dougherty wrote​:

But it would introduce new issues where the result on a single platform depended on the language used to generate that result.

It is ridiculous to apply such a standard to Perl's built-in stringification of numeric values\, which is an entirely language-specific concept. Where you want Perl's output to appear in some externally-imposed format\, to match other code on the same platform or for any other reason\, you should use explicit formatting code.

-zefram

p5pRT commented 10 years ago

From @csjewell

On Wed\, Aug 7\, 2013\, at 9​:37\, Andy Dougherty wrote​:

On Wed\, Aug 07\, 2013 at 06​:59​:03AM -0700\, "Ed Avis via RT" wrote​:

I suggest the general issue is not the leading spaces but that infinity stringifies differently on different platforms\, making it difficult for Perl code which looks at that string representation.

It would certainly be worthwhile to make Perl return a single string such as 'Inf' no matter what the platform. That would squash this bug and all future bugs of the same kind.

But it would introduce new issues where the result on a single platform depended on the language used to generate that result. At various times with various projects\, I have wanted it both ways. I don't have any easy answer.

I think I may have another angle to attack this from - could we add a $Config{'stringified_infinity'} (or something to that effect) for cross-platform code to compare against? Unixy stuff could determine it via a configure test\, other platforms could hard-code.

--Curtis Jewell -- Curtis Jewell csjewell@​cpan.org http​://csjewell.dreamwidth.org/ perl@​csjewell.fastmail.us http​://csjewell.comyr.org/perl/

"Your random numbers are not that random" -- perl-5.10.1.tar.gz/util.c

Strawberry Perl for Windows betas​: http​://strawberryperl.com/beta/

p5pRT commented 10 years ago

From @epa

Curtis Jewell \<perl \ csjewell.fastmail.us> writes​:

could we add a $Config{'stringified_infinity'} (or something to that effect) for cross-platform code to compare against?

It would be more useful to have a standard is_infinity() function on scalars\, along with is_nan(). Perhaps there is even a CPAN module which provides this already.

However\, that doesn't remove the need to standardize the string representation. It is all too easy to start relying on 'Inf' or some other string in your code\, causing a portability bug you won't discover until you try running it on another platform. There should be a single string representation which is guaranteed everywhere\, so that people who don't read this list\, and so are unaware of the nasty details of C library floating point string printing\, can remain in blissful ignorance and still write code that isn't buggy.

-- Ed Avis \eda@&#8203;waniasset\.com

p5pRT commented 10 years ago

From @Hugmeir

On Wed\, Aug 7\, 2013 at 12​:45 PM\, Curtis Jewell \perl@&#8203;csjewell\.fastmail\.uswrote​:

On Wed\, Aug 7\, 2013\, at 9​:37\, Andy Dougherty wrote​:

On Wed\, Aug 07\, 2013 at 06​:59​:03AM -0700\, "Ed Avis via RT" wrote​:

I suggest the general issue is not the leading spaces but that infinity stringifies differently on different platforms\, making it difficult for Perl code which looks at that string representation.

It would certainly be worthwhile to make Perl return a single string such as 'Inf' no matter what the platform. That would squash this bug and all future bugs of the same kind.

But it would introduce new issues where the result on a single platform depended on the language used to generate that result. At various times with various projects\, I have wanted it both ways. I don't have any easy answer.

I think I may have another angle to attack this from - could we add a $Config{'stringified_infinity'} (or something to that effect) for cross-platform code to compare against? Unixy stuff could determine it via a configure test\, other platforms could hard-code.

Quick interjection that you'd also have to do it for NaN (1.#IND in windows\, nan on mac\, NaN on android\, etc). I have no opinion on whenever standardizing makes sense or not.

As a side note\, thanks to the "1." in Window's output\, looks_like_number() correctly assumes that those two are numbers without special casing. Hooray(?). On the other hand\, it fails on my stricter implementation. Boo.

p5pRT commented 10 years ago

From zefram@fysh.org

Ed Avis wrote​:

It would be more useful to have a standard is_infinity() function on scalars\, along with is_nan(). Perhaps there is even a CPAN module which provides this already.

Data​::Float​::float_is_{infinite\,nan}.

-zefram

p5pRT commented 5 years ago

From @khwilliamson

On Wed\, 07 Aug 2013 11​:37​:17 -0700\, zefram@​fysh.org wrote​:

Ed Avis wrote​:

It would be more useful to have a standard is_infinity() function on scalars\, along with is_nan(). Perhaps there is even a CPAN module which provides this already.

Data​::Float​::float_is_{infinite\,nan}.

-zefram

Cn we close this ticket?

-- Karl Williamson

p5pRT commented 5 years ago

From @khwilliamson

On Wed\, 07 Aug 2013 11​:37​:17 -0700\, zefram@​fysh.org wrote​:

Ed Avis wrote​:

It would be more useful to have a standard is_infinity() function on scalars\, along with is_nan(). Perhaps there is even a CPAN module which provides this already.

Data​::Float​::float_is_{infinite\,nan}.

-zefram

Cn we close this ticket?

-- Karl Williamson

khwilliamson commented 4 years ago

No one commented in 6 months. Closing