[rrd-developers] Improvements to rrd_strerror.

Sebastian Harl sh at tokkee.org
Fri Feb 13 09:04:41 CET 2009

Hi Tobi, Florian,

On Thu, Feb 12, 2009 at 03:35:05PM +0100, Florian Forster wrote:
> Please note, that error checking with
>   if (strerror_r (...)) { ... }
> is problematic for portability: Some systems (the GNU libc, unless given
> _XOPEN_SOURCE=600, for example) export a version of `strerror_r' that
> returns a pointer to the buffer it just filled, so it can be used just
> like `strerror'. On such systems the block will always be executed
> *except* when an error occurred.

Unfortunately, it's even worse than that. The GNU version of strerror_r
might not even return a pointer to the user provided buffer (the second
argument to strerror_r) but possibly some pointer to some static string.
So, even if the error checking was correct, an empty string or garbage
might have been returned from rrd_strerror when returning
ctx->lib_errstr in that case. The latter case might even cause segfaults
if no '\0' appears in the garbage.

autoconf provides a macro to check for the type of the return value of
strerror_r. At runtime, we need to check which string to return (either
the return value of strerror_r or the user provided buffer).

The patch that I'm going to provide in a second tries hard to handle all
possible cases. It's derived from the implementation that Florian and I
came up with in collectd over the time (there have been around O(4)
[*scnr*] commits until we caught [hopefully] every possibly case).


Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety.         -- Benjamin Franklin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.oetiker.ch/pipermail/rrd-developers/attachments/20090213/b1bc1346/attachment.bin 

More information about the rrd-developers mailing list