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
Comments
From david.dyck@fluke.comCreated by david.dyck@fluke.comI tried to use CPAN's Set::Infinite, which seems to On my computer perl reports perl -wle 'print q(").(100**100**100).q(")' It's my guess that this may be a libc5 issue, but does My old perl3 and perl4 binaries also The following test program in C doesn't display int main() { which prints Perl Info
|
From enache@rdslink.roOn Fri, Sep 05, 2003 a.d., David Dyck wrote:
what does your perl say for: $ perl -MConfig -le 'print $Config{d_Gconvert}' ? Regards, |
From @ysthOn Fri, Sep 05, 2003 at 12:46:28AM -0000, David Dyck <perlbug-followup@perl.org> wrote:
Try configuring with -Dd_Gconvert='sprintf((b),"%.*g",(n),(x)),strcpy((b),strtok((b)," "))' (Is strcpy guaranteed to work with overlapping strings?)
Perhaps the libc bug is only triggered when a precision is given, e.g. |
From david.dyck@fluke.comOn Fri, 5 Sep 2003 at 17:09 -0000, Adrian Enache <perlbug-followup@perl.org...:
$ perl -MConfig -le 'print $Config{d_Gconvert}' I guess to get the leading spaces that print uses $ perl -wle 'printf q(")."%15g".qq("\n), (100**100**100)' |
From enache@rdslink.roOn Fri, Sep 05, 2003 a.d., Yitzchak Scott-Thoennes wrote:
From the linux strtok manpage: BUGS 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 Regards, |
From enache@rdslink.roOn Fri, Sep 05, 2003 a.d., Yitzchak Scott-Thoennes wrote:
No, it's not. |
From enache@rdslink.roOn Fri, Sep 05, 2003 a.d., David Dyck wrote:
You could try a small C program to see if sprintf((b),"%-.*g",(n),(x)) is triggering the same bug. Regards, |
From david.dyck@fluke.comOn Fri, 5 Sep 2003 at 22:28 +0300, Enache Adrian <enache@rdslink.ro> wrote:
Not quite the same For which values of n above? int main() { char b[128]; return 0; n=-15 <Inf> |
From @mjdominusEnache Adrian <enache@rdslink.ro>:
strtok() is a red herring; he should be using strchr() for that. However, strcpy() is *not* guaranteed to work on overlapping buffers; |
From @ysthOn Fri, Sep 05, 2003 at 05:52:44PM -0400, Mark Jason Dominus <mjd@plover.com> wrote:
Umm, no. strtok is what I want. And those "bugs" are exactly what strtok
Given that perl is always going to pass a 64 or 20+NV_DIG byte buffer, In any case, this isn't how I would propose a change to configure, just |
From @ysthOn Fri, Sep 05, 2003 at 02:21:54PM -0700, David Dyck <david.dyck@fluke.com> wrote:
Look at perl.h for DBL_DIG and you will see a humongous block of code |
From david.dyck@fluke.comOn Fri, 5 Sep 2003 at 18:17 -0000, Yitzchak Scott-Thoennes <perlbug-followu...:
I tried this and got The new perl reports
sprintf(buf, "%.*g", DBL_DIG, inf); |
From david.dyck@fluke.comOn Fri, 5 Sep 2003 at 23:02 -0000, Yitzchak Scott-Thoennes <perlbug-followu...:
Yes, I see it. |
From david.dyck@fluke.com
Just to follow up - I don't get the test failures Will perl get test cases or will it remain platform dependent? |
From @smpeters
Are you still getting the odd results with perl -wle 'print q(").(100**100**100).q(")' If so, may I ask what Linux you are running? |
From david.dyck@fluke.comOn Wed, 10 May 2006 at 18:08 -0700, Steve Peters via RT <perlbug-followup@p...:
This is what I get today dd:dcd$ perl -wle 'print q(").(100**100**100).q(")' Linux dd 2.4.33-pre3 #1 Mon May 1 07:22:46 PDT 2006 i686 as you can see, my libc is 'older' :-) dd:dcd$ ls -l /lib/libc.so.5 dd:dcd$ ls -lL /lib/libc.so.5 |
From @ysthOn Wed, May 10, 2006 at 06:41:31PM -0700, David Dyck wrote:
I remember someone reporting this before with an old libc. They got it working with an evil hack involving setting d_Gconvert |
From @smpetersOn Wed, May 10, 2006 at 06:59:29PM -0700, Yitzchak Scott-Thoennes wrote:
This would be that ticket :). Just making sure there is a Steve Peters |
From @HugmeirOn Thu Sep 04 17:46:28 2003, dcd wrote:
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
This bug report hasn't seen any activity in seven years. I can't [*] Archlinux: Debian wheezy: CentOS 5.6 & 6: OpenSUSE: Gentoo: Android 4.0.4: Mac OS X 10.8.4: QNX Neutrino: Windows Server 2008: Windows Server 2008, cygwin: Syllable: Haiku: Solaris 11: OmniOS: FreeBSD 9.0: NetBSD 5.1.2: OpenBSD 5.0: --hugmeir |
From @epaI suggest the general issue is not the leading spaces but that infinity It would certainly be worthwhile to make Perl return a single string |
From @doughera88On Wed, Aug 07, 2013 at 06:59:03AM -0700, "Ed Avis via RT" wrote:
But it would introduce new issues where the result on a single -- |
From zefram@fysh.orgAndy Dougherty wrote:
It is ridiculous to apply such a standard to Perl's built-in -zefram |
From @csjewellOn Wed, Aug 7, 2013, at 9:37, Andy Dougherty wrote:
I think I may have another angle to attack this from - could we add a --Curtis Jewell "Your random numbers are not that random" -- perl-5.10.1.tar.gz/util.c Strawberry Perl for Windows betas: http://strawberryperl.com/beta/ |
From @epaCurtis Jewell <perl <at> csjewell.fastmail.us> writes:
It would be more useful to have a standard is_infinity() function on scalars, However, that doesn't remove the need to standardize the string -- |
From @HugmeirOn Wed, Aug 7, 2013 at 12:45 PM, Curtis Jewell <perl@csjewell.fastmail.us>wrote:
Quick interjection that you'd also have to do it for NaN (1.#IND in As a side note, thanks to the "1." in Window's output, looks_like_number() |
From zefram@fysh.orgEd Avis wrote:
Data::Float::float_is_{infinite,nan}. -zefram |
From @khwilliamsonOn Wed, 07 Aug 2013 11:37:17 -0700, zefram@fysh.org wrote:
Cn we close this ticket? -- |
1 similar comment
From @khwilliamsonOn Wed, 07 Aug 2013 11:37:17 -0700, zefram@fysh.org wrote:
Cn we close this ticket? -- |
No one commented in 6 months. Closing |
Migrated from rt.perl.org#23731 (status was 'open')
Searchable as RT23731$
The text was updated successfully, but these errors were encountered: