> This behavior, by itself, does not necessary guarantee > that your OpenSSL library code won't race against itself, > won't corrupt its own data, or crash (hint: learn about > the MySQL case, search the archives).
"it's own data"?? - well this is exactly why I asked on this list :-) I wanted to get a better I idea about what "it's own data" actually means. I am growing toward a complete list of "it's own data" that does not appear to have any chance of races. The fact that yee-all aren't sure what "it's own data" precisely means makes me a bit worried!!! :-) > IMHO, your approach is clearly wrong: your app's fate > is relying on undocumented behavior. It could "work" with > a few OpenSSL library versions; but internal, sentitive > behavior could change in future versions. Hence, I don't > consider this a good engineering practice. My approach is certainly wrong by definition. It practice, for the OpenSSL source tree I am using, it is 100% working. Yes, you are right - future versions could break everything. > I won't argue with you about using the library in an > undocumented manner; but I *do* think it'd be interesting > to get some real quantitative data: we could use it as a > basis to discuss possible future library modifications, > more compatible with your requests. I want to implement a static analyzer to work out all of OpenSSL's global variables, and incapsulate them in a global instance of the library. I have done this before with a library thus enabling me to instantiate multiple instances of a libary. I believe global variables in a library are bad practice. -paul
