On Fri, 4 Apr 2003, Markus Baertschi wrote: > Date: Fri, 04 Apr 2003 19:54:40 +0200 > From: Markus Baertschi <[EMAIL PROTECTED]> > To: Tobias Oetiker <[EMAIL PROTECTED]> > Cc: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> > 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:[EMAIL PROTECTED] Help mailto:[EMAIL PROTECTED] Archive http://www.ee.ethz.ch/~slist/rrd-developers WebAdmin http://www.ee.ethz.ch/~slist/lsg2.cgi
