[perl #40823] Win32 vs. the world - length for sprintf('%e') - what's right?

[Chip Salzenberg]

# New Ticket Created by Chip Salzenberg
# Please include the string: [perl #40823]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40823 >

Please somebody figure out what Perl does on Win32 for testing sprintf,
because the Perl sprintf test suite seems to think that the right value
for sprintf('%e',1) is "1e+00", but Win32 seems to return "1e+000" (note
the extra digit in the exponent). Is this true? If so, is it a bug? In
any case, how does the Perl test suite not fail on Win32?
--
Chip Salzenberg <ch...@pobox.com>

[Nicholas Clark]

On Sat, Nov 11, 2006 at 04:34:55PM -0800, Chip Salzenberg wrote:

> Please somebody figure out what Perl does on Win32 for testing sprintf,
> because the Perl sprintf test suite seems to think that the right value
> for sprintf('%e',1) is "1e+00", but Win32 seems to return "1e+000" (note
> the extra digit in the exponent). Is this true? If so, is it a bug? In

(As an aside, well, "yes" it's a bug in as much as Win32's C library is not
ANSI conformant. (I read about this somewhere, possibly p5p). Someone said
that Microsoft missed a trick in that their folks on the C standardisation
committee could have re-drafted the standard to allow 3 or 2 digit exponents,
instead of just 2, and made this non-buggy)

> any case, how does the Perl test suite not fail on Win32?

As to a useful answer, er, I don't know. Sorry.

Nicholas Clark

[SADAHIRO Tomoyuki]

On Sat, 11 Nov 2006 16:34:55 -0800, Chip Salzenberg (via RT) wrote

> because the Perl sprintf test suite seems to think that the right value
> for sprintf('%e',1) is "1e+00", but Win32 seems to return "1e+000" (note
> the extra digit in the exponent). Is this true? If so, is it a bug? In
> any case, how does the Perl test suite not fail on Win32?

It just drops the superfluous zero from the return value.
Even if sprintf(">%e<", 1234.875) on win32 returns ">1.234875e+003<"
here $y is ">1.234875e+03<" that comes to be equal to ">$result<".
In this way these three-digit exponents are accepted.

# Cf. perl-current/t/op/sprintf.t
$x = sprintf(">$template<", @$data);
substr($x, -1, 0) = $w if $w;
# $x may have 3 exponent digits, not 2
my $y = $x;
if ($y =~ s/([Ee][-+])0(\d)/$1$2/) {
..........
}
..........
if ($x eq ">$result<") {
print "ok $i\n";
}
elsif ($skip) {
print "ok $i # skip $comment\n";
}
elsif ($y eq ">$result<") # Some C libraries always give
{ # three-digit exponent
print("ok $i # >$result< $x three-digit exponent accepted\n");
}

Regards,
SADAHIRO Tomoyuki

[Jerry Gay]

On 11/13/06, SADAHIRO Tomoyuki <bqw1...@nifty.com> wrote:
> On Sat, 11 Nov 2006 16:34:55 -0800, Chip Salzenberg (via RT) wrote
>
> > because the Perl sprintf test suite seems to think that the right value
> > for sprintf('%e',1) is "1e+00", but Win32 seems to return "1e+000" (note
> > the extra digit in the exponent). Is this true? If so, is it a bug? In
> > any case, how does the Perl test suite not fail on Win32?
>
> It just drops the superfluous zero from the return value.
>

ick -- that feels wrong for parrot. we've always tried to make parrot
act in a consistent way across platforms wherever possible, so i'd
rather see the fix in Parrot_sprintf rather than in t/op/sprintf.t.

~jerry

[Allison Randal]

jerry gay wrote:
>>
> ick -- that feels wrong for parrot. we've always tried to make parrot
> act in a consistent way across platforms wherever possible, so i'd
> rather see the fix in Parrot_sprintf rather than in t/op/sprintf.t.

For the record: we decided in the weekly meeting yesterday to go with a
platform-independent implementation with consistent behavior.

Allison