tech-userlevel archive

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

Re: strtonum(3) from OpenBSD?

Am 05.08.2009 um 22:34 schrieb Joerg Sonnenberger:

On Wed, Aug 05, 2009 at 10:15:39PM +0200, Marc Balmer wrote:

Am 23.06.2009 um 17:05 schrieb Joerg Sonnenberger:

On Tue, Jun 23, 2009 at 04:28:11PM +0200, Marc Balmer wrote:
If there are no particular reasons why it is not in NetBSD, I would
to make an effort to port it and mail a diff.

At the very least, the interface should use intmax_t instead of long
long.  That it only supports signed values is another issue, but can

so why does strsuftoll return long long?

Because that's what the name is promising?

ok, but....

almost everything that has been brought up against having strtonum in libc is present in strsuftoll(x): it returns long long, it uses a string for error reports, it does not support i18n etc.... So all the arguments gainst strtonum are somewhat void.

OTOH this strsuftoll is only present in NetBSD, whereas strtonum is present in OpenBSD and FreeBSD. It would ease porting software if we had strtonum in NetBSD, too.

To me strsuftoll(x) looks like an over engineered forme of strtonum, with all the same deficiencies people claim strtonum has.

strtonum is small and clean and only deals with numbers. not kiibi, mebi, bubi stuff. just numbers. I don't want a GPIO pin number be specied in blocks, that is so weird....

So we agree to accumulate local copies of strtonum? Just because we don't like the strtonum API, which is kind of like the strsuftoll API which we have in tree?

- em-be


Home | Main Index | Thread Index | Old Index