NetBSD-Bugs archive

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

Re: lib/58453: endptr can be unitialized if an invalid base is passed to strto*(3)



The following reply was made to PR lib/58453; it has been noted by GNATS.

From: Christos Zoulas <christos%zoulas.com@localhost>
To: Robert Elz <kre%munnari.OZ.AU@localhost>,
 Taylor R Campbell <riastradh%NetBSD.org@localhost>
Cc: gnats-bugs%netbsd.org@localhost,
 Christos Zoulas <christos%astron.com@localhost>,
 netbsd-bugs%netbsd.org@localhost
Subject: Re: lib/58453: endptr can be unitialized if an invalid base is passed
 to strto*(3)
Date: Mon, 22 Jul 2024 17:58:14 -0400

 > On Jul 22, 2024, at 5:52=E2=80=AFPM, Robert Elz <kre%munnari.OZ.AU@localhost> =
 wrote:
 >=20
 > What exactly is this bug report about?
 >=20
 > The referenced message from Alejandro Colomar is about about
 > just strtoi() (which used strtoimax() incorrectly) and which
 > you fixed.
 >=20
 > That the other strto*() functions don't leave any defined value
 > in *endptr when an invalid base is provided (which is really just
 > a bug in the application) isn't unexpected, as Alejandro's 2nd
 > message indicates, and POSIX makes expicit:
 >=20
 > APPLICATION USAGE
 >            Since the value of *endptr is unspecified if the value of =
 base
 > 	    is not supported, applications should either ensure that =
 base
 >            has a supported value (0 or between 2 and 36) before the =
 call,
 > 	    or check for an [EINVAL] error before examining *endptr.
 >=20
 > The test program provided in this PR is incorrect, as it fails to make =
 that
 > check (especially as it is explicitly providing an invalid base).
 >=20
 > kre
 >=20
 > ps: Note that this doesn't mean that we couldn't put something =
 specific
 > in *endptr in the case of an invalid base, but anything which ends up
 > relying upon that would be broken.  Perhaps we could set it to NULL or
 > (void *)-1 so any attempt to dereference it would fault, though =
 technically
 > simply referencing it is UB.
 
 Our implementation sets it to the beginning of the string. I know it is =
 allowed
 to UB when the base is invalid, but since out implementation initializes =
 it,
 the test works. I think that there is a disadvantage to adding the test =
 in that
 it enforces a behavior which is strictly not required. So if the tests =
 were used
 on Linux for example, they would fail.
 
 christos
 


Home | Main Index | Thread Index | Old Index