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

perl5 sprintf: wrong output on format %a #16327

Closed
p5pRT opened this issue Dec 20, 2017 · 8 comments
Labels

Comments

@p5pRT
Copy link
Collaborator

@p5pRT p5pRT commented Dec 20, 2017

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

Searchable as RT132626$

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 20, 2017

From wolf-dietrich_moeller@t-online.de

This is a bug report for perl from wolf-dietrich_moeller@​t-online.de,
generated with the help of perlbug 1.40 running under perl 5.26.1.


sprintf generates a wrong output for the format "%a".
The test program below gives the output lines​:

0x1.ep+4 30.000000 3.000000e+001 30
0x1.ep+4 0X1.EP+4 30.000000 30

Line 1 shows the buggy result of "%a".
Line 2 shows that under certain combinations of format
parameters the bug even extends to the next parameter.

######## test program #########
print sprintf("%a %f %e %g\n",30,30,30,30);
print sprintf("%a %e %f %g\n",30,30,30,30);
######## end test program #####



Flags​:
  category=core
  severity=medium


Site configuration information for perl 5.26.1​:

Configured by strawberry-perl at Sat Sep 23 23​:10​:19 2017.

Summary of my perl5 (revision 5 version 26 subversion 1) configuration​:
 
  Platform​:
  osname=MSWin32
  osvers=6.3
  archname=MSWin32-x86-multi-thread-64int
  uname='Win32 strawberry-perl 5.26.1.1 #1 Sat Sep 23 23​:07​:28 2017 i386'
  config_args='undef'
  hint=recommended
  useposix=true
  d_sigaction=undef
  useithreads=define
  usemultiplicity=define
  use64bitint=define
  use64bitall=undef
  uselongdouble=undef
  usemymalloc=n
  default_inc_excludes_dot=define
  bincompat5005=undef
  Compiler​:
  cc='gcc'
  ccflags =' -s -O2 -DWIN32 -D__USE_MINGW_ANSI_STDIO
-DPERL_TEXTMODE_SCRIPTS -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS
-DUSE_PERLIO -fwrapv -fno-strict-aliasing -mms-bitfields'
  optimize='-s -O2'
  cppflags='-DWIN32'
  ccversion=''
  gccversion='7.1.0'
  gccosandvers=''
  intsize=4
  longsize=4
  ptrsize=4
  doublesize=8
  byteorder=12345678
  doublekind=3
  d_longlong=define
  longlongsize=8
  d_longdbl=define
  longdblsize=12
  longdblkind=3
  ivtype='long long'
  ivsize=8
  nvtype='double'
  nvsize=8
  Off_t='long long'
  lseeksize=8
  alignbytes=8
  prototype=define
  Linker and Libraries​:
  ld='g++'
  ldflags ='-s -L"C​:\Perl\perl\lib\CORE" -L"C​:\Perl\c\lib"'
  libpth=C​:\Perl\c\lib C​:\Perl\c\i686-w64-mingw32\lib
C​:\Perl\c\lib\gcc\i686-w64-mingw32\7.1.0
  libs= -lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32
-ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr
-lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32
  perllibs= -lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32
-ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr
-lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32
  libc=
  so=dll
  useshrplib=true
  libperl=libperl526.a
  gnulibc_version=''
  Dynamic Linking​:
  dlsrc=dl_win32.xs
  dlext=xs.dll
  d_dlsymun=undef
  ccdlflags=' '
  cccdlflags=' '
  lddlflags='-mdll -s -L"C​:\Perl\perl\lib\CORE" -L"C​:\Perl\c\lib"'


@​INC for perl 5.26.1​:
  C​:/Perl/perl/site/lib
  C​:/Perl/perl/vendor/lib
  C​:/Perl/perl/lib


Environment for perl 5.26.1​:
  HOME (unset)
  LANG (unset)
  LANGUAGE (unset)
  LD_LIBRARY_PATH (unset)
  LOGDIR (unset)
  PATH=<content
cleared>;C​:\Perl\c\bin;C​:\Perl\perl\site\bin;C​:\Perl\perl\bin
  PERL_BADLANG (unset)
  SHELL (unset)

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 20, 2017

From zefram@fysh.org

Wolf-Dietrich Moeller wrote​:

print sprintf("%a %f %e %g\n",30,30,30,30);
0x1.ep+4 30.000000 3.000000e+001 30
Line 1 shows the buggy result of "%a".

That looks correct to me. What output were you expecting for %a?

print sprintf("%a %e %f %g\n",30,30,30,30);
0x1.ep+4 0X1.EP+4 30.000000 30
Line 2 shows that under certain combinations of format
parameters the bug even extends to the next parameter.

There's certainly a bug there, with %e producing the wrong output.
Apparently that's triggered by coming immediately after %a. But it
seems unlikely that this would have anything to do with whatever it is
that you perceive to be wrong about the output of %a.

-zefram

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 20, 2017

The RT System itself - Status changed from 'new' to 'open'

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 20, 2017

From @sisyphus

-----Original Message-----
From​: Wolf-Dietrich Moeller (via RT)
Sent​: Wednesday, December 20, 2017 10​:57 PM
To​: bugs-bitbucket@​rt.perl.org
Subject​: [perl #132626] perl5 sprintf​: wrong output on format %a

# New Ticket Created by Wolf-Dietrich Moeller
# Please include the string​: [perl #132626]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=132626 >

This is a bug report for perl from wolf-dietrich_moeller@​t-online.de,
generated with the help of perlbug 1.40 running under perl 5.26.1.

-----------------------------------------------------------------
sprintf generates a wrong output for the format "%a".
The test program below gives the output lines​:

0x1.ep+4 30.000000 3.000000e+001 30
0x1.ep+4 0X1.EP+4 30.000000 30

Line 1 shows the buggy result of "%a".
Line 2 shows that under certain combinations of format
parameters the bug even extends to the next parameter.

######## test program #########
print sprintf("%a %f %e %g\n",30,30,30,30);
print sprintf("%a %e %f %g\n",30,30,30,30);
######## end test program #####
-----------------------------------------------------------------

I see the same on Strawberry 5.26.0 (gcc-7.1.0), and on my own mingw-w64
build of 5.26.0 (gcc-7.2.0).

However, on my own build of 5.27.6 (gcc-7.2.0), the output of the test
program is correct.

Since the only difference between my build of 5.26.0 and my build of 5.27.6
is the perl source, I surmise that the perl source has already been patched
to fix the bug.

Cheers,
Rob

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 20, 2017

From zefram@fysh.org

I wrote​:

Wolf-Dietrich Moeller wrote​:

print sprintf("%a %e %f %g\n",30,30,30,30);
0x1.ep+4 0X1.EP+4 30.000000 30

There's certainly a bug there, with %e producing the wrong output.

This was fixed by commit 5d10f2f in
Perl 5.27.1.

$ perl5.27.1 -we 'print sprintf("%a %e %f %g\n",30,30,30,30)'
0x1.ep+4 3.000000e+01 30.000000 30

-zefram

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 21, 2017

@iabyn - Status changed from 'open' to 'pending release'

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 23, 2018

From @khwilliamson

Thank you for filing this report. You have helped make Perl better.

With the release yesterday of Perl 5.28.0, this and 185 other issues have been
resolved.

Perl 5.28.0 may be downloaded via​:
https://metacpan.org/release/XSAWYERX/perl-5.28.0

If you find that the problem persists, feel free to reopen this ticket.

@p5pRT p5pRT closed this Jun 23, 2018
@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 23, 2018

@khwilliamson - Status changed from 'pending release' to 'resolved'

@p5pRT p5pRT added the Severity Low label Oct 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant
You can’t perform that action at this time.