At Tue, 23 Jun 2009 23:18:57 +0200, Adam Hoka <adam.hoka%gmail.com@localhost>
wrote:
Subject: Re: strtonum(3) from OpenBSD?
>
> Well the main problem is, that a lot of stuff in src/ totally lacks
> error checking when they parse integers. Try passing INT_MIN-1 to
> random apps on command line. :-)
>
> Though they could be fixed in the standard way, but thats a lot of
> code duplication.
The silly idea of writing a wrapper around strtol() or strtoll() is that
this is all about the aspect of standardising error handling, input
requirements, and range checking. That's the sole purpose of such a
wrapper since the actual underlying function still does all the real
work.
However as this thread shows quite well I think, fixing all these rules
and only allowing this task to be done in one way is like trying to fit
a square peg into a round hole. Indeed I'm sure there were similar
discussions, and perhaps many more, in the ANSI/IEEE committees who
first created strtol() and friends.
The whole idea behind strtol() as it has been designed is to provide the
widest range of flexibility possible to meet the largest sane set of
different input, range checking, and error handling requirements.
So to me making a rigid libutil (or libc) interface around strtol()
seems kinda silly unless you really do have a significantly largish
number of uses where _all_ those aspects of its use really can be
standardised more easily with a wrapper than by simply using the code
block given as the example in strtol(3).
If I look at code I've written using, or modified to use, strtol() or
strtoll() or strtoq() there's never anything easily factored into a
simple wrapper interface. Each use is in some small way unique. The
duplication of code Adam worries about above really isn't replicated
enough to worry me at all.
--
Greg A. Woods
Planix, Inc.
<woods%planix.com@localhost> +1 416 218-0099 http://www.planix.com/
Attachment:
pgphpTDczDbMT.pgp
Description: PGP signature