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

Tobias Oetiker oetiker at ee.ethz.ch
Sat Apr 5 10:26:19 MEST 2003

Today Peter Stamfest wrote:

> Just to clarify things: I can absolutely understand how this started. That
> is how such projects work. You always end up with something suboptimal.

sure no problem ...

> 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).

... and now is the time to change things ... that is what the 1.1.x
branche is for ... realy, I am totally open ... in the same way as
the calling interface would need work, a more generic data output
structure would be sensible I think ... maybe along the lines of
rrd_info ...

> 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.

partly this is due to the fact that we are using an binary
representation internally, but do you think this matters, what is
the precision we loose when you enter enough digits to be on the
sure side ?

> 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 have unfortunately realy not much experiance here ... other
libraries must have somilar problems ...


 ______    __   _
/_  __/_  / /  (_) Oetiker @ ISG.EE, ETZ J97, ETH, CH-8092 Zurich
 / // _ \/ _ \/ /  System Manager, Time Lord, Coder, Designer, Coach
/_/ \.__/_.__/_/   http://people.ee.ethz.ch/~oetiker   +41(0)1-632-5286

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

More information about the rrd-developers mailing list