Questionable behavior of strtoi(3bsd) / strtou(3bsd)

[Alejandro Colomar]

Hi!

On Mon, Jan 08, 2024 at 11:34:40PM +0100, Guillem Jover wrote:
[...]
> Ah, thanks for the analysis you did on the other sub-thread, I guess
> though there's the potential for third-party projects that are not part
> of the NetBSD source tree, to opportunistically use a system strtoi(),
> which could also become bogus. A quick scan over the results from a
> Debian codesearch revealed some uses that seem to match this API:
> 
>   https://codesearch.debian.net/search?q=%5B%5Ea-z_%5Dstrtoi%5B%5B%3Aspace%3A%5D%5D*%5C%28&literal=0&perpkg=1&page=8
> 
> But I didn't stop to check whether these would become bogus or not.

Here's an analysis of (hopefully) all strtoi() and strtou() calls in
Debian (via <https://codesearch.debian.net/>):

	# [^a-z_]strto[iu][[:space:]]*\( 
alx at debian:~/tmp$ curl -s https://codesearch.debian.net/results/75d504410b08061f/packages.txt > pkgs_strtoiu.txt
	# ERANGE
alx at debian:~/tmp$ curl -s https://codesearch.debian.net/results/7bfe90cb8fc22956/packages.txt > pkgs_erange.txt
	# ENOTSUP
alx at debian:~/tmp$ curl -s https://codesearch.debian.net/results/f58b317a98a306b8/packages.txt > pkgs_enotsup.txt
alx at debian:~/tmp$ cat pkgs_erange.txt pkgs_enotsup.txt | sort | uniq > pkgs_errno.txt
	# Only calls where either ERANGE or ENOTSUP are checked can be
	# affected by changing the API to return ERANGE instead of
	# ENOTSUP.
alx at debian:~/tmp$ cat pkgs_strtoiu.txt pkgs_errno.txt | sort | uniq -d > need_check_strtoiu.txt
alx at debian:~/tmp$ cat need_check_strtoiu.txt 
ats2-lang
bglibs
cypari2
dhcpcd
fpc
libbsd
linphone
llvm-toolchain-14
llvm-toolchain-15
llvm-toolchain-16
llvm-toolchain-17
mk-configure
poke
r-base
r-cran-data.table
r-cran-ps
r-cran-vroom
spectrwm
swiftlang


	# Let's see each of the above.

ats2-lang
	False positive, I think.  Custom strtoi().

bglibs
	False positive, I think.  Custom strtou().

cypari2
	False positive, I think.  Custom strtoi().

dhcpcd
	BUG!  This package has bugs caused by the current definitions of
	strtoi(3bsd) and strtou(3bsd), and would be fixed by my
	suggested API:

	<https://sources.debian.org/src/dhcpcd/1:10.0.6-1/src/if-linux.c/?hl=268#L268>
	<https://sources.debian.org/src/dhcpcd/1:10.0.6-1/src/if-linux.c/?hl=2238#L2238>
	<https://sources.debian.org/src/dhcpcd/1:10.0.6-1/src/if-linux.c/?hl=252#L252>
	<https://sources.debian.org/src/dhcpcd/1:10.0.6-1/compat/pidfile.c/?hl=161#L161>

	Nothing would break by changing the API.

fpc
	False positive, I think.

libbsd
	Would need to change the implementation of strtonum(3bsd), as
	NetBSD would also have to, if we change strtoi(3bsd).  It's an
	easy change, though.

linphone
	False positive.  Custom strtoi().

llvm-toolchain-14
llvm-toolchain-15
llvm-toolchain-16
llvm-toolchain-17
	I've only checked -17.  Nothing would break.

mk-configure
	Nothing would break.

poke
	False positive, I think.

r-base
	False positive.  Custom strtoi().

r-cran-data.table
r-cran-ps
r-cran-vroom
	These seem to use the definition from r-base.  False positives.

spectrwm
	Nothing would break.

swiftlang
	Nothing would break.



> Searches through google code search or github might reveal more users,
> but that might be tiresome to go through (or you might not feel like
> using those services at all :D).

I don't feel like using those services at all.  :D

> > > If the function changes in NetBSD, I'm happy to import those changes,
> > > but I don't think I'd be comfortable doing that unilaterally in libbsd.
> > > I'd suggest you file a bug report in the NetBSD bug tracker.
> > 
> > Sure; will do.  I'll send a few more emails to this thread with the
> > results of my search in NetBSD's code, and when I have all the info I
> > want, I'll file a bug there.
> 
> Thanks for filing the report! You might want to mention explicitly
> there the analysis you have done on their source tree, as I'd assume
> they could easily skip reading the referenced thread.

Sure!  I'll also copy the Debian analysis, in case they wonder about
non-NetBSD users.

> > Bon any,
> 
> (Igualment! :)
> 
> Thanks,
> Guillem

Have a lovely day!
Alex

-- 
<https://www.alejandro-colomar.es/>
Looking for a remote C programming job at the moment.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/libbsd/attachments/20240109/6fed9278/attachment.sig>