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

Bug#162917: [bcollins@debian.org: Re: Bug#162917: libc6: strftime crashes with invalid input]



Ben Collins <bcollins@debian.org>:
> On Tue, Oct 01, 2002 at 09:05:12AM +1000, Hamish Moffatt wrote:
>> strftime() causes a segmentation fault if some of the values in the tm
>> argument are outside of its expected range. Here is a sample program:
> 
> Lots of things segfault on unexpected data. Why should this be any
> different? SUSv2 specifies the expected ranges for struct tm:
> ...
> Anything else is obviously undefined. Since SUSv2 defines the range on
> the input parameters, it should not be expected that that all functions
> using struct tm should have to verify all members of struct tm fit into
> the range. That is the job of the caller.
> 
> Unless you can provide statements to the contrary, I'll close this bug.

In general, one should try to avoid seg faults.  That includes both libc
developers and application developers.  For example, Xpdf tries to catch
bad PDF files and print an error, rather than simply seg faulting. (Hey,
running xpdf on a file that's not up to the PDF spec is undefined
behavior, right?)

However...

A seg fault indicates a bogus pointer.  If I call

    printf("%s", bogusPointer);

it's not unreasonable for printf to seg fault.  If I'm debugging
this code, I will say "oh, a bogus pointer", and quickly find the
problem (i.e., that I passed a bogus pointer into printf).

(But even nicer behavior would be to do something like "(null)", which
is exactly what glibc's printf does.)

If strftime returns an empty string, or doesn't modify the string at
all, or really any other result (it's undefined behavior, as you said),
that would be fine.  I claim that seg faulting in this situation is bad
behavior (makes it harder to find the problem in my code -- I initially
started by trying to figure out if I passed a bogus pointer to
strftime).

Anyway, I've worked around this in my code.  I'm just trying to make
life a little easier for the next guy who runs into this.

- Derek




Reply to: