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

[Peter Stamfest]

On Fri, 4 Apr 2003, Tobias Oetiker wrote:

> Date: Fri, 4 Apr 2003 23:01:03 +0200 (MEST)
> From: Tobias Oetiker <oetiker at ee.ethz.ch>
> To: Peter Stamfest <peter at stamfest.at>
> Subject: Re: [rrd-developers] Re: rrdtool libraries segfault with getopt
> 
> Today Peter Stamfest wrote:
> >
> > 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.

Just to clarify things: I can absolutely understand how this started. That
is how such projects work. You always end up with something suboptimal.  
This is natural. I cannot think of a single of my projects where
_everything_ went smoothly and the end-product was perfect. If I am not
satisfied I tend to rewrite whole applications... ;-) I would not do this
with the rrdtool, however. Conclusion: Early design decisions often tend 
to get in the way of a project later on.

> 
> If one of you wants to designe a more 'reasonable' calling
> interface for the rrdtool functions, please post your plan to the
> rrd-developers list ... (and later send a patch :-) )

I am not saying that the current implementation is bad: It has its
problems, but for some areas there are now replacements/extensions (the
*_r function for some operations do not use getopt for two reasons:  
Non-threadable and as mentioned before: using getopt multiple times is not
the Right Thing to do).

One more thing I want to add to this discussion: There is one problem that
I encountered recently that partly has to do with the fact that all
communication to the RRD functions is through strings: RRDs essentially
store values of type "double". If one wants to put a double value into an
RRD using all significant places of such a double then things get hairy:  
Who can name a printf-format specifier that garantees that one gets _all_
significant places? I have no answer how to properly handle this situation 
right now. And communicating through strings also slows down things 
unneccessarily.

One possibility would be to go variadic, it is supposed to be 
portable, but it is definitly ugly as well. It might solve some of the 
problems, but would add others.

It could all end up like this:

* Keep rrd_update as it is:

  rrd_update(int argc, char **argv)

* Make rrd_update_r variadic [and at the same time hand an RRD instead of 
  a filename]:

    rrd_update_r(rrd_t rrd, char *format, ...)

  This beast would call vrrd_update_r (similar to printf and vprintf):

    vrrd_update_r(rrd_t rrd, char *format, va_list va)

  which in turn does the ugly work.

BUT: How to turn a *char[] into a va_list in order to have rrd_update call 
vrrd_update_r?

AND: I think not all rrd_* functions can be rewritten like this. Just like 
not all do exist in *_r variants right now.


This probably is not the best solution, but maybe it adds to the 
discussion.

> I am not at all a fan of my implementation, I was just 'out of
> ideas' on how to handle the complex parameters required for the
> rrdtool functions

I really, really _do_ understand (the last sentence, that is).


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