[olsr-dev] Re: Die "%m", die

[Bernd Petrovitsch]

On Mon, 2006-01-09 at 10:33 +0100, Roar Bjørgum Rotvik wrote:
[....]
> But a little note:
> The error string from strerror() is a static string that may be changed
> by either sterror() or perror(). From "man strerror":
> "The strerror() function returns a string describing the error code
> passed in the argument errnum, possibly using the LC_MESSAGES part of
> the current locale to select the appropriate language.  This string must
> not be modified by the application, but may be modified by a subsequent
> call to perror() or strerror(). No library function will modify this
> string."

Ooops.

[...]
> This means that the call to strerror() will store the error string from
> sendto(), but as the man page for strerror() indicates, the call to
> perror() may overwrite this static string and the call to olsr_syslog()
> may in fact return error string from perror()... :)

Yes.

> What about storing the actual errno instead of the string as in this
> example?
> 	if (olsr_sendto(...) < 0)
>  	{
>           const int my_errno = errno;
>  	  perror("sendto(v4)");
> 	  olsr_syslog(OLSR_LOG_ERR, "OLSR: sendto IPv4 %s", strerror (my_errno));
>  	  netbufs[ifp->if_nr]->pending = 0;
>  	  return -1;
>  	}
> But then you need to call strerror(my_errno) as many times as you need
> the string..

Yup. Makes more sense then.
My strategic problem with the error reporting actually is: I can't see
in a simple way, what should be reported when and via which means and
how should it be configurable (at compile-time and at run-time).
There is perror() at some places, there is the OLSR_FPRINTF macro, there
is syslog() and in different combination at different places.

Perhaps Andreas T. or Thomas L. can put some light on this (and I'm not
so interested in the history but more on the goal or features)?!

Im my simple world, a function like "void olsr_error(int level, const
char * const format, ...);"[0] should hide all the magic (probalby with
configuration variables) if perror() should be used, syslog(), or
whatever and how the messages should be filtered.

> I'm not trying to be difficult, it's nice that someone creates patches

/me neither. I just see potential bugs there sitting around ...

> to fix bugs or add features. Just trying to avvoid any more bugs even if
> the possibility for these bugs is very small :)

It's even worse - these places are under #ifdef influence (in the
OLSR_PRINTF macro) and actually error handling, so even if you want to
actually test it, you (probably) have to construct manually special test
cases for each of them and this is IMHO more effort than adhering to a
consistent programming style and get at least correct information (and I
hate it to look for an error cause and find major bugs in the error
reporting code hours later ....).

	Bernd

[0]: Yes, I didn't forget the Win-Problems with errno/strerror and I
     have possible solutions for this in my head - namely, passing errno
     as parameter and #define macros and similar preprocessor magic to
     avoid passing it explicitly.
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services