> On Sun, 2008-01-20 at 11:59 -0800, David Schwartz wrote: > > Most definitely not. At a minimum, the definition of things > > like 'errno' and > > 'malloc' might be different between a multithreaded build and a > > non-multithreaded build. There is no supported way to combine > > multithreaded > > code and code that was not compiled to be multithreaded.
> > It may happen to work, but that's a lousy way to make security-sensitive > > software. > Definitely not true on gcc+glibc Umm, definitely true. > - there is no difference between > multithreaded and non-multithreaded _compilation_ (surely not for errno > and malloc). Really? So 'errno' refers to a process global in both cases?! (Note that I said the "definition", not the implementation.) > So it is pretty safe to use non-multithreaded libraries (if > they are reentrant) in multithreaded applications on gcc+glibc. Of > course at link time and especially run time, the code being executed in > glibc is very different. The problem is that it is neither specified to work nor guarantee to work. You may enjoy writing security-sensitive software that "just happens to work" where you have to retest your assumptions with every new version of the system libraries, but I don't. I hope you don't dynamically-link such a thing. You have no way of knowing if the glibc libraries you might happen to run-time link to will work. When you use "features" that aren't guaranteed, a newer version may break the assumptions and still claim compatability. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
