[musl] strtod behaving differently in glibc and musl

[musl] strtod behaving differently in glibc and musl

[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

Re: [musl] strtod behaving differently in glibc and musl

[Markus Wichmann]

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