From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 70BDE24AE2 for ; Thu, 29 Feb 2024 17:50:30 +0100 (CET) Received: (qmail 26524 invoked by uid 550); 29 Feb 2024 16:46:47 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 26486 invoked from network); 29 Feb 2024 16:46:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=s31663417; t=1709225416; x=1709830216; i=nullplan@gmx.net; bh=IVcjDQmnNWPS56yupcjJRtDBBl1jqhD5/Kfaw1MPLAo=; h=X-UI-Sender-Class:Date:From:To:Cc:Subject:References: In-Reply-To; b=S2jnl+ps3q8Exwaonp9Yb9awF7b0SPEdenoOfY80WizT1CQdu2wQC6/PEv7nqW7c XqEigqbtyxd/CNd/kjtRjhSw6NLdc6a8ErI3X83Hzgi+VjfoUDlQpluT/Hyt+CLZ3 l3URArD36/Jj+6XwP3lysmaua2RTiL54TaXx+x2ZkgsIBamwVzzgGUrI7RipV26rR k0YlGG3rb9en32ekWlh+6Ap9GlHfTbRNotw7Rng3Iq3DGjDTCqOZSHBHiR2D4m3UP YofwzTrXbsIDaP11v1syxOkVunIALqc3ltYjLs1B7niliYsPAeYnfzQYXRag9oGsO Tfxj4UMgDbLMPMQE1g== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Date: Thu, 29 Feb 2024 17:50:14 +0100 From: Markus Wichmann To: musl@lists.openwall.com Cc: Marian Buschsieweke Message-ID: References: <20240229172738.0a9a62da@flerken.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240229172738.0a9a62da@flerken.lan> X-Provags-ID: V03:K1:NQRdV9fK7InUbLO3P4oexGS8UP6jc22QFTYu4M6rMMF2ZU+GF1f M6C9WWX7+JWKEHOQU+ltyDVIeVDBAXMvhtyz2HMl7dhcBftdwT/sp6+j93sNdVw3wFAxWDn AOnmXi4ZsnPuL+NRN6g+oUr5QREJ8fUa9L4ureW1XZRrcyw9lrWWhuxuIHRgXWwS1A+M9Tr ylfL1UACMIaxEkVl/nQkQ== UI-OutboundReport: notjunk:1;M01:P0:gGHifLHVguk=;Nsx1KX7tUDtW15ai1UKtHjphDcF MlFR4fXcl/+NBHsGrr9e/39cYgAOmxWtpApAX0enKUOWWHVxox8qJjsHDAd50tXrjjaiG7E69 oeHgUu0PTGzl2FTvdeCF49A4+b8YsadC9OuoOONe3+Kko8onQ/0yq717GZHgMceETle4/NeAF hTjC1ESR4x1fDLoMgBWlCVgS/0CfolPgvLX3+Ju00uq8NbijdjBDnnwpeDLaX2zLGSs8Pp+n9 h6iNxKb4XzP7b/nOzvyisChG4T8knCtzmOclrGpR++V+nGAN9LPpwl8THLY3SZytS8Pz57CiB vcoi2LyPIKoPLfZXdv5OLGWGlUs3HGPISQxQu2gEiG9+Q6NBb+3+XwEhH8v2nvtXErTei33gi njj17BVU1t93dIngIQwcDhfjfHFeMaoEGn+d5U27MBq4pgAHCNXsMyZBRo02wvObXSBNNYP1h YySIt2ul98sGjJWTmPlz0AE/0Pa1/m4Cq/qwxzc56QgmLN5sy39C++4+jswn+67I5fWYo7CjA p3zivTEIys+kJG8QLGV3OpvTBK3W9oatWU3JPQW8r8JJzEPHRoKnQm/0ECBAfBTy3RXxIoKog 4rCMf0kXq11+Glh0HExI37sow0hyCTTHAGzOZZ5MreuTCr25i46GDNg37WUelZwKC1UD1VnAK qGbGuHEJDb+ju+iuJ8NFb4uFBfNKLz3wHVPY1nt32B4LH92WEIW22oyXBi1V/oEONwmLwiK+9 DXNu1WcGoJ/x0YOwKVOyAhERt4Ej6KpyvdTRyE2djHRmzPwm/bF2ms4GIDanmg1XjegLhR42F BLQNChO5S3HSOkrdJd3up3pZL0fna3bxVIFKu1eKEMFyc= Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] 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 i= s 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 b= ehave > 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 z= ero, > 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 th= e 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