Date: Tue, 12 Apr 2005 19:35:03 +0000 (UTC) From: Thorsten Glaser <tg@66h.42h.de> To: freebsd-current@freebsd.org, miros-discuss@mirbsd.org, tech@openbsd.org Subject: Re: strtonum(3) in FreeBSD? Message-ID: <Pine.BSO.4.61L.0504121932540.4031@odem.66h.42h.de> In-Reply-To: <1113334228.27362.35.camel@localhost.localdomain> References: <1113334228.27362.35.camel@localhost.localdomain>
next in thread | previous in thread | raw e-mail | index | archive | help
Dixitur: >> Quick, sort of, question. Is it worth it to bring strtonum(3) from >> OpenBSD into FreeBSD-CURRENT. I have the diffs if that's the case, I >> know that the newer packet filter code from OPENBSD_3_7 that mlaier@ and >> I are working on uses it in a few places (see: pflogd) but I'm not sure >> of the merits of bringing strtonum(3) into lib/libc/stdlib... >> >> In theory, it should be a better implementation of what atoi(3) and >> strtol(3) do, but as tg@(mirbsd.org) pointed out to the OpenBSD fellows >> and myself, it doesn't take hexadecimal values well... >> >> Somebody let me know, i've got diffs ready, sort of ;) >> (or let me know why it's a bad idea) > >The lack of base handling argument does make it less appealing, but now >that OpenBSD has used this name, we're stuck with the API. I would Accepting "0x10" as 16 instead of 0 is no API breakage, it only changes the behaviour. To the good, I might add. I'd suggest to not add octal (010) parsing, because leading zeroes are not totally uncommon in the purely-decimal world. >request that you use intmax_t rather than "long long" for the integers. >Then the API scales cleanly when some future processor adds 128-bit ints. >Since intmax_t is "long long" on all current platforms that wouldn't >cause compatability problems with OpenBSD. I second that. Cc'd to OpenBSD-Tech. Comments? //mirabile
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSO.4.61L.0504121932540.4031>