[olsr-dev] [PATCH] Improvements in dot_draw plugin
Tue Nov 8 14:21:22 CET 2005
On Tue, 2005-11-08 at 13:49 +0100, Thomas Lopatic wrote:
> > On Tue, 2005-11-08 at 12:43 +0100, Thomas Lopatic wrote:
> >> > Is "%m" in printf()s and the like considered portable?
> >> This doesn't work on Windows. So I am afraid, no.
> > Hmm, do you ever plan to implement olsr_syslog (e.g. to write something
> > into the Win* event log)?
> Hmm, no, not yet. Would that help us with the "%m" issue?
No. We should than eliminate %m from olsr_syslog() calls.
Some of them are buggy anyways since using syslog() and printf() both
may change errno if there is an error.
> "%m" on Linux is easy, as every API function that we use in olsrd sets
> errno. To implement "%m" the C library can thus simply take errno, run it
> through strerror() and display the message.
> On Windows it's bit more complicated. The Windows port currently uses two
> sources of error information instead of the single "errno" macro known
> from Linux: WSAGetLastError() and GetLastError(). The former is used to
> obtain error messages supplied by the Windows socket implementation, the
> latter is used for all other API functions. I could imagine that this is
So you have to call it outside of the olsr_syslog() call since you need
to know where look (or use two different olsr_syslog() functions).
*eg* The simple solution is to use two macros (or inline functions) like
wsa_get_last_error_str() and get_last_error_str() and #define both of
them for Unixens to "strerror(errno)". And which to use where is left
for the Win* folks .....
> also one of the reasons why "%m" is not supported by msvcrt.dll. Too many
> sources of error information on the OS.
Hmm, the obvious replacement is to use `"%s", strerror(errno)`. But this
doesnt' help either.
So basically the question is: Should we kill the %m in olsr_syslog()
Or should we kill %m in all possibly non-Unix code?
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
More information about the Olsr-dev