[rrd-developers] Re: rrdtool libraries segfault with getopt

[Peter Stamfest]

On Fri, 4 Apr 2003, Markus Baertschi wrote:

> Date: Fri, 04 Apr 2003 19:54:40 +0200
> From: Markus Baertschi <markus at markus.org>
> To: Tobias Oetiker <oetiker at ee.ethz.ch>
> Cc: "rrd-developers at list.ee.ethz.ch" <rrd-developers at list.ee.ethz.ch>
> Subject: [rrd-developers] Re: rrdtool libraries segfault with getopt
> 
> 
> Tobi,
> 
> I've done some experimenting and can found, that the rrd_* routines
> require that the optind variable is set to zero before calling them.
> If you use getopt the optind variable points to the last argument
> in your respective argv after the array is processed. Getopt picks
> up where it left using this method. As this is standard unix proctice
> , I feel that the rrd_* routines should reset optind to zero before 
> getopt processing. 
> One could argue the user of getopt should reset optind to zero after
> each usage of getopt, but I've never seen this done. At the moment 
> the rrd_* routines assume that getopt is zero, which breaks them for
> any program using getopt itself.

True.

On a more general level I consider any repeated use of getopt "broken" in
any case, as one can never be sure what a particular getopt implementation
is _really_ doing behind the scenes. As long as one deals with just one 
particular implementation a work-around is fine, but when the porting 
starts...

I think this all started with the creation of "librrd", a really great
idea, but the understandable design decision to rely on getopt for
variable length argument handling within the stand-alone tools turned sour 
when those tools ended up together in the library. This is "living 
history" we deal with here.

peter

--
Unsubscribe mailto:rrd-developers-request at list.ee.ethz.ch?subject=unsubscribe
Help        mailto:rrd-developers-request at list.ee.ethz.ch?subject=help
Archive     http://www.ee.ethz.ch/~slist/rrd-developers
WebAdmin    http://www.ee.ethz.ch/~slist/lsg2.cgi