Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
p5pRT opened this issue Sep 5, 2003 · 29 comments
Closed

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

p5pRT opened this issue Sep 5, 2003 · 29 comments

Comments

@p5pRT
Copy link

p5pRT commented Sep 5, 2003

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

Searchable as RT23731$

@p5pRT
Copy link
Author

p5pRT commented Sep 5, 2003

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
<Inf>

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
Copy link
Author

p5pRT commented Sep 5, 2003

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
Copy link
Author

p5pRT commented Sep 5, 2003

From @ysth

On Fri, Sep 05, 2003 at 12​:46​:28AM -0000, David Dyck <perlbug-followup@​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
<Inf>

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
Copy link
Author

p5pRT commented Sep 5, 2003

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@​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
Copy link
Author

p5pRT commented Sep 5, 2003

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
Copy link
Author

p5pRT commented Sep 5, 2003

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
Copy link
Author

p5pRT commented Sep 5, 2003

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
Copy link
Author

p5pRT commented Sep 5, 2003

From david.dyck@fluke.com

On Fri, 5 Sep 2003 at 22​:28 +0300, Enache Adrian <enache@​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 <Inf>
n=-14 <Inf>
n=-13 <Inf>
n=-12 <Inf>
n=-11 <Inf>
n=-10 <Inf>
n=-9 <Inf>
n=-8 <Inf>
n=-7 <Inf>
n=-6 <Inf>
n=-5 <Inf>
n=-4 <Inf>
n=-3 <Inf>
n=-2 <Inf>
n=-1 <Inf>
n=0 <Inf>
n=1 <Inf>
n=2 <Inf>
n=3 <Inf>
n=4 <Inf >
n=5 <Inf >
n=6 <Inf >
n=7 <Inf >
n=8 <Inf >
n=9 <Inf >
n=10 <Inf >
n=11 <Inf >
n=12 <Inf >
n=13 <Inf >
n=14 <Inf >
n=15 <Inf >

@p5pRT
Copy link
Author

p5pRT commented Sep 5, 2003

From @mjdominus

Enache Adrian <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\.

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
Copy link
Author

p5pRT commented Sep 5, 2003

From @ysth

On Fri, Sep 05, 2003 at 05​:52​:44PM -0400, Mark Jason Dominus <mjd@​plover.com> wrote​:

Enache Adrian <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\.

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
Copy link
Author

p5pRT commented Sep 5, 2003

From @ysth

On Fri, Sep 05, 2003 at 02​:21​:54PM -0700, David Dyck <david.dyck@​fluke.com> wrote​:

On Fri, 5 Sep 2003 at 22​:28 +0300, Enache Adrian <enache@​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
Copy link
Author

p5pRT commented Sep 5, 2003

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@​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
Copy link
Author

p5pRT commented Sep 6, 2003

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@​perl.org>

On Fri, Sep 05, 2003 at 02​:21​:54PM -0700, David Dyck <david.dyck@​fluke.com> wrote​:

On Fri, 5 Sep 2003 at 22​:28 +0300, Enache Adrian <enache@​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
Copy link
Author

p5pRT commented Oct 7, 2005

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
Copy link
Author

p5pRT commented May 11, 2006

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
Copy link
Author

p5pRT commented May 11, 2006

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@​perl.org>
To​: "Dyck, David" <david.dyck@​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
Copy link
Author

p5pRT commented May 11, 2006

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@​perl.org>
To​: "Dyck, David" <david.dyck@​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
Copy link
Author

p5pRT commented May 11, 2006

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@​perl.org>
To​: "Dyck, David" <david.dyck@​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
Copy link
Author

p5pRT commented Aug 7, 2013

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
<Inf>

[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
Copy link
Author

p5pRT commented Aug 7, 2013

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
Copy link
Author

p5pRT commented Aug 7, 2013

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
Copy link
Author

p5pRT commented Aug 7, 2013

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
Copy link
Author

p5pRT commented Aug 7, 2013

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
Copy link
Author

p5pRT commented Aug 7, 2013

From @epa

Curtis Jewell <perl <at> 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@​waniasset.com>

@p5pRT
Copy link
Author

p5pRT commented Aug 7, 2013

From @Hugmeir

On Wed, Aug 7, 2013 at 12​:45 PM, Curtis Jewell <perl@​csjewell.fastmail.us>wrote​:

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
Copy link
Author

p5pRT commented Aug 7, 2013

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
Copy link
Author

p5pRT commented Mar 25, 2019

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

1 similar comment
@p5pRT
Copy link
Author

p5pRT commented Mar 25, 2019

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
Copy link
Contributor

No one commented in 6 months. Closing

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants