Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 29 Feb 2024 17:50:14 +0100
From: Markus Wichmann <nullplan@....net>
To: musl@...ts.openwall.com
Cc: Marian Buschsieweke <marian.buschsieweke@...teo.net>
Subject: Re: strtod behaving differently in glibc and musl

Am Thu, Feb 29, 2024 at 04:27:38PM +0000 schrieb Marian Buschsieweke:
> Hi,
>
> ngspice is parsing tokens from a string input that may either be numeric of
> strings using strtod. The man page states explicitly that if the input is not a
> valid number (and also no special token such as "inf" or "nan"), that it should
> return zero and set endptr to nptr. In this regard both musl and glibc behave
> the same.
>
> The difference is that musl will set errno to EINVAL a non-numeric input (which,
> from the common sense point of view, makes sense). glibc sets errno to zero,
> which is the behavior that ngspice is expecting.
>
> The man page for strtod is surprisingly ambiguous in this regard. To me, it is
> unclear which behavior is correct and whether this should be fixed on the musl
> side or on the ngspice side.
>
> Any thoughts on this?
>
> Thanks!
>
> Kind regards,
> Marian

POSIX is ambiguous on this. On one hand, the "return value" section for
strtod says that if no conversion can be performed, strtod() "shall" set
errno to EINVAL. On the other hand, the "errors" section says EINVAL is
only a may-fail.

In any case, the ambiguity is only over whether the behavior you see is
required or merely allowed. ngspice assuming it doesn't happen is just
wrong. The correct way to test if any conversion happened is to compare
the final value of endp with the first argument, because if no
conversion could happen, endp *must* be set to the first argument.

Ciao,
Markus

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.