-
Notifications
You must be signed in to change notification settings - Fork 553
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
POSIX shouldn't test signbit(NAN) #21533
Comments
|
I think that some people would prefer to know that It seems to me that in this instance that @rkennedy has reported, @rkennedy, could you confirm that when the perl-5.38.0 you've quoted runs the following script: it outputs: Cheers, |
|
Yes, Perl 5.38.0 prints both Based on my understanding of how the POSIX standard defines NAN, I think Unless math.t has some additional knowledge of how the underlying Maybe there's some way for the test to determine the underlying behaviors, without using the |
|
Yes, I see the same on 32-bit MSVC-built perl-5.38.0 on Windows: But perl itself does it differently: On that Windows build, the POSIX signbit tests are skipped, as the signbit function doesn't work correctly anyway. The current But if that assumption is not deemed "valid and desirable", then the That snippet requires that the POSIX, Test::More and Config modules have been loaded - which t/math.t has already done. I haven't really thought about what would be needed for the "Double-Double" long double builds. (My PPC64 box running Debian is currently unusable,) Cheers, |
|
Is copysign() supports NAN, from C99 "7.12.11.1 The copysign functions": "They produce a NaN (with the sign of y) if x is a NaN" |
The test in Configure warns: /* Note that whether the sign bit is on or off * for NaN depends on the CPU/FPU, and possibly * can be affected by the build toolchain. but this test assumed that the default NaN was always positive, but this isn't the case with the Sun/Oracle workshop cc, whether on Oracle Linux or on Solaris. copysign() is however well defined for NaN, so we can modify the sign on NaN and test that with signbit(). Fixes Perl#21533
The test in Configure warns: /* Note that whether the sign bit is on or off * for NaN depends on the CPU/FPU, and possibly * can be affected by the build toolchain. but this test assumed that the default NaN was always positive, but this isn't the case with the Sun/Oracle workshop cc, whether on Oracle Linux or on Solaris. copysign() is however well defined for NaN, so we can modify the sign on NaN and test that with signbit(). Fixes Perl#21533
The test in Configure warns: /* Note that whether the sign bit is on or off * for NaN depends on the CPU/FPU, and possibly * can be affected by the build toolchain. but this test assumed that the default NaN was always positive, but this isn't the case with the Sun/Oracle workshop cc, whether on Oracle Linux or on Solaris. copysign() is however well defined for NaN, so we can modify the sign on NaN and test that with signbit(). Fixes #21533
Module: POSIX
Description
ext/POSIX/t/math.t includes an assertion about
signbit(NAN), and it fails while I'm trying to build v5.38.0:It's this assertion:
ok(!signbit(NAN), "signbit(NAN)");The assertion fails on my Solaris x86 system. The underlying C
signbitfunction exhibits the same behavior.That prints
NaN sign bit: 1. (On my Solaris Sparc system, and on my RHEL x86_64 host, it reports "0" instead, and Perl'ssignbittest passes.)Steps to Reproduce
./Configure -Dcc=/bin/cc -des -Dusethreads -Duseshrplib=false -Dnoextensions=ODBM_File make make test TEST_FILES=../ext/POSIX/t/math.tExpected behavior
This particular assertion shouldn't be present. POSIX does not specify the precise value of NAN. Although NAN values may have sign bits, they do not have signs, per se, so it's wrong to assert that the value of NAN's sign bit should have any particular value.
This is somewhat related to issue #18473, and especially to PR #18590, where the failing assertion was added.
Perl configuration
The text was updated successfully, but these errors were encountered: