"Miquel van Smoorenburg" <[EMAIL PROTECTED]> wrote: > Well, you should be able to link against thread-safe variants of > those functions, right? I mean, strtok() is obviously not > thread safe, but localtime() should be.
Nope. Log into a *BSD box. The thread-safe variant of localtime() is localtime_r(). Localtime returns a pointer to static data, which can be over-written in subsequent calls. I've *never* understood why people designed functions which returned pointers to static data. They don't even scale on *one* process, much less multi-threaded. e.g. Try to keep two different pointers to data returned by two subsequent calls to localtime(), for two different dates. You can't. You get the same pointer both times. So the second call over-writes the data from the first call. So the only sane way to use that function even in a process with one thread of execution, is to copy the results to another buffer. But if that's true, why the heck didn't localtime just take a pointer to the place to store the returned data? But I digress... > It's probably just a matter of linking against the right library. > libc_r instead of libc, most likely. libc_r usually has the foo_r() functions. libc() doesn't. libc_r usually *also* has the unsafe foo() functions, so people who want to shoot themselves in the foot can do so. > I think Linux turns on thread-safety if you define -DREENTRANT > and link with -pthreads. Other systems might need other > magic incantations. Like FreeBSD, and probably Solaris. glibc does *insane* things to be thread-safe while returning pointers to static data. That's why Linux doesn't have the foo_r() functions. It's also why glibc is so much larger and more complicated than the *BSD C libraries. They're trying to be smart & cute, instead of writing simple, clean, code. > Don't just substitute all library functions for their _r equivalents, > just find out how to link against the thread-safe libc variant. The server has been linking that way for a while, and it isn't good enough. People other than the glibc hackers run away screaming when asked to make thread-safe versions of localtime(), etc. The simplest thing to do is to *always* use the localtime_r() functions, and to have a trivial wrapper around localtime() using 'memcpy' to get the same effect. I've made that change in the server for ctime_r() and for localtime_r(). If it *creates* problems, I'd love to know. IMHO, *all* of the functions returning pointers to static data should just go away. They're badly designed. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
