[Top][All Lists]

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

Re: glibc segfault on "special" long double values is _ok_!?

From: Jim Meyering
Subject: Re: glibc segfault on "special" long double values is _ok_!?
Date: Wed, 06 Jun 2007 18:05:42 +0200

Andreas Schwab <address@hidden> wrote:
> Jim Meyering <address@hidden> writes:
>> Andreas Schwab <address@hidden> wrote:
>>> Jim Meyering <address@hidden> writes:
>>>> Andreas Schwab <address@hidden> wrote:
>>>>> Jim Meyering <address@hidden> writes:
>>>>>> I'm interested, because I don't want my applications to segfault on such
>>>>>> inputs.  Sure it may look a little far-fetched, but I think it's not.
>>>>>> Imagine such a bit pattern being injected into a network data stream
>>>>>> that is then printed as a long double.  Just printing an arbitrary
>>>>>> "long double" should not make a server vulnerable to a DoS attack.
>>>>> In which way is this different from passing NULL to strlen?
>>>> I'm surprised to hear you arguing that it is desirable for glibc's printf
>>>> implementation to segfault for a long-double with an unusual bit pattern.
>>> In which way is this different from printf("%s", (char*)1)?
>> Posing the question for printf("%s", NULL) wouldn't have made
>> the same point, Eh?
> You still did not answer my questions.

[ off-topic debate games...

    In a way, I did answer them by talking about undefined behavior,
    which is what they all evoke.  However, I avoided answering
    directly because the actual answers are not relevant, since as I
    said from the start, this is a quality of implementation issue,
    and has no bearing on conformance.

    If I had said this was a bug, or that this behavior made glibc
    non-conforming (to some standard), then your questions would have
    been perfectly relevant, and would have put me firmly in my place
    for making what would have amounted to a false accusation.
    However, I did neither of those things.

I just want to be able to write robust code, and if glibc doesn't
provide the tools to do that, then I think it's fair to expect a
change, or at least an explanation for why change is not possible.

So, would you argue that robust code must first ensure each
arbitrary-bit-pattern long double is valid before printing it?
Obviously, that is required now, given glibc's current behavior, but
should it be required forever?  If so, this should be documented,
along with a description of how to detect the offending values.
The fpclassify macro cannot be used, because it declares the
offending value to be FP_NORMAL.  Application code should not have
to limit itself to printing only values for which isnanl returns 0.

My original point is that this bug report deserves more than
a summary dismissal:


At the very least, it deserves an explanation of why a segfault should
remain glibc/printf's response to an invalid long double bit pattern.

But glibc deserves better than that.

reply via email to

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