Re: lib/49429: Import strtonum(3)

["Kamil Rytarowski" <n54%gmx.com@localhost>]

Hello,

Please let me sum the discussion in this thread (and nod cross-list it).

1.
Joerg, thank you. I have checked all the discussions that were held in NetBSD and FreeBSD.

Ab ovo: strtonum(3) was added as a safe replacement for atoi(3) in ping(8) in OpenBSD back in old days. The friendly devs were using strtol-like functions and struggling hard with simple coding bugs.

To use properly strol-like function in order to convert a decimal number to a literal representation (as noted in a mail at FreeBSD [1]), a friendly developer has to do the following:

           char *ep;
           int ival;
           long lval;

           ...

           errno = 0;
           lval = strtol(buf, &ep, 10);
           if (buf[0] == '\0' || *ep != '\0')
                goto not_a_number;
           if ((errno == ERANGE && (lval == LONG_MAX || lval == LONG_MIN)) ||
               (lval > INT_MAX || lval < INT_MIN))
                goto out_of_range;
           ival = lval;


It's a bit complex replacement for atoi(3), isn't it? int a = atoi(buf);

It was said that in order to the design flaws in strtonum(3) it was rejected. The designers say that the "flaws" were design-choice, as a strtol-like -- I don't want to give all pros and cons here, please look at the relevant discussions, eg. at the FreeBSD ml [2].

In my opinion this should be considered differently:
- if someone wants safe atoi(3) replacement will switch to strtonum(3),
- if someone wants to handle cases with trailing characters, will use atoi(3),
- if someone wants to handle special cases (different base, complex error handling) will stay with strtol-like functions

I think that some developers want to consider strtonum(3) as a strtol(3) (or sscanf(3)) replacement, what is wrong. And here is the key of our misunderstanding (safe atoi on steroids vs 'orchestra' function).

2.
Christos,

Please don't add burden to devs and users placing the function in a different place, resulting in an include-jitsu for NetBSD vs the world.

3.
Steffen, thank you for looking for 'false-positives' :-)

4.
Martin,

Improving the API is (like intmax_t strtoinum(), uintmax_t strtounum()), to me as a user is as long OK as it's compatible with the code around.

Last but the last, if strtonum(3) would be considered harmful it would not be used for new code outside the place of its origins (timeout(1)).

Best regards!

BTW. For your interest, I have received positive feedback ('good luck') from OpenBSD devs in private mails.

[1] http://lists.freebsd.org/pipermail/freebsd-current/2005-April/048745.html
[2] http://lists.freebsd.org/pipermail/freebsd-current/2005-April/048744.html