bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gnulib portability issues


From: Eric Blake
Subject: Re: gnulib portability issues
Date: Tue, 12 Jun 2012 08:02:58 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1

On 06/12/2012 07:46 AM, Rich Felker wrote:

>> Actually, there IS a need to handle these representations.  The 'od'
>> program in coreutils is an example of where POSIX requires us to handle
>> ANY bit pattern as given in an arbitrary input file as ANY other type of
>> number, including long doubles.  And that means that all possible bit
>> patterns, even the invalid LD80 representations that cannot occur as a
>> result of arithmetic, CAN occur via memory aliasing, and we really do
>> desire to output those as NaN via the use of isnanl().
> 
> So isnanl is expected to be slower in every program that's using it
> for legitimate arithmetic purposes for the sake of one program's ease
> of implementing a non-standard and mostly useless feature? How often
> have you heard of anybody running od to dump a file of raw LD80
> values? If this feature is desired, the test for invalid
> representations belongs in od itself, where the cost only affects od,
> not in every single mathematical program.
> 
> If you were just using gnulib to replace isnanl in od, it wouldn't be
> such an issue. But considering printf broken, and replacing printf
> because of this, is a big issue. Replacing printf is non-trivial, and
> might not even work (for instance if your replacement of printf
> happens to call some standard library function that the implementation
> happened to implement in terms of printf, you get infinite recursion).
> Attempting to replace "big" functions like printf should be avoided
> unless absolutely necessary.

You have a fair argument here, but Bruno needs to weigh in on it since
it was his decision to mark printf 'broken' when handed undefined input.
 I agree with you that printf("%Ld",n) not printing "NaN" for undefined
input is a much different case than isnanl(n) not returning true for
out-of-range input.  It would indeed be feasible to say that printf() is
POSIX compatible if it correctly handles all inputs that are only
possible via defined arithmetic, and require that programs like od that
translate bit patterns into numbers outside of arithmetic take extra
steps to sanitize pseudo-denormals into something that will be printed
correctly rather than blindly pass all bit patterns to printf directly.
 That may still require an isnanl() replacement, but hopefully Bruno
would agree that a printf() replacement is overkill.

> 
>>> 3. The test for "POSIX compatible" getopt does not actually test for
>>> POSIX compatibility, but for GNU semantics which are contrary to
>>> POSIX. This is purely an issue of a misnamed test; if gnulib wants to
>>> provide a replacement getopt with GNU semantics, that's okay, but it
>>> should not tell the user that the host getopt is not "POSIX
>>> compatible".
>>
>> We've already separated the getopt module into tests for POSIX behavior
>> vs. tests for GNU extension behavior.  Which particular aspect are you
>> claiming is incorrectly attributed to POSIX behavior when it should be
>> treated as GNU behavior instead?  And is this occurring when the
>> getopt-gnu module is in use, or is it reproducible when using just the
>> getopt-posix module?  Or is this just a case of inaccurate wording but
>> accurate testing?
> 
> I was testing with GNU m4. The test that fails has non-option
> arguments placed before options, and tests to see if it can get the
> option with getopt.

GNU m4 requires the GNU extensions to getopt; so this may be a case of
just inaccurate wording in the configure output.  Also, the last release
tarball of m4 (1.4.16, Mar 2011) predates some gnulib improvements to
the getopt module, so if that was the version you were testing, it might
also be a symptom of something that would be fixed by me doing a refresh
release of m4 against newer gnulib.

-- 
Eric Blake   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]