db_strerror is thread safe?

Thanks, Florian -- that's a good suggestion, I hadn't thought of that.

That approach requires a change in the Berkeley DB db_strerror API (or
a new API, db_strerror_r, I suppose). Is there enough risk here to
make an API change necessary?

You can avoid the API change if you use thread-local storage (today,
this is very cheap on many systems) for the buffer, or if you memoize
the return strings for each error number.

Berkeley DB is thread-agnostic, so thread-local storage isn't available
to us.

Currently, all error return strings are in text space, this is only an
issue for errors for which there is no matching text string (which
should only happen if there is a bug in the application, calling
db_strerror with an illegal value, or in Berkeley DB, returning an
illegal return vlaue).

Regards,
--keith

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Keith Bostic bostic (AT) sleepycat (DOT) com
Sleepycat Software Inc. keithbosticim (ymsgid)
118 Tower Rd. +1-781-259-3139
Lincoln, MA 01773 http://www.sleepycat.com

Berkeley DB is thread-agnostic, so thread-local storage isn't available
to us.

Using "real" TLS means that you just write

static __thread buffer[1024];

or

static __declspec(thread) buffer[1024];

And the C run-time library works behind the scenes to make this buffer
thread-specific. I would be surprised if the embedded targets haven't
added this interface in the meantime, too.

Currently, all error return strings are in text space, this is only an
issue for errors for which there is no matching text string (which
should only happen if there is a bug in the application, calling
db_strerror with an illegal value, or in Berkeley DB, returning an
illegal return vlaue).

This is the code which is really problematic:

if (error > 0) {
if ((p = strerror(error)) != NULL)
return (p);
goto unknown_err;
}

strerror may need to dynamically allocate the return string, too. 8-(