Re: strtonum(3) in FreeBSD?

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_at_ 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_at_(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