On Tue, Nov 16, 1999 at 10:30:10PM +0000, Geoff Thorpe wrote:
>> Maybe we should have a naming convention for ..._set_... calls too?
>> There are already such ambiguities for them, e.g. SSL_CTX_set_tmp_rsa
>> vs. SSL_CTX_set_tmp_dh.
> It seems to be a play-off between backwards compatibility, and having a
> good library-API. I prefer the latter, but I don't have as much legacy
> code to maintain as some others do, and I probably find the current
> "inconsistencies" a little more distasteful than some others do.
I don't like them either (especially the SSL_CTX_set_tmp_rsa / dh
example because they are "obviously" similar, but behave quite
differently), but if we change this and get rid of the existing API
then we have to change function names so that old code does not even
compile, or there'll be tons of _non-obviously_ broken applications,
which would be really, really bad.
> It seems that
> everything works if you make the calls the way the authors had intended
> rather than making the calls the way the authors made available.
How can you tell what is the "intended" way? For SSL_get_session, the
code consistently assumes that no free-ing is necessary (cf. apps/s_*.c),
althoughly surely it would have made sense to demand it.
> If 0.9.4 has faults, surely it is preferable to fix them in 0.9.5 and for
> dependant code to stick with 0.9.4 until it has been brought in line with
> 0.9.5's fixes.
The trouble is that 0.9.4 has various bugs which should be fixed for
all applications before upgrading to the new library version becomes
too difficult.
[...]
> As SSL_get_session is an exported API function and
> SSL_SESSION has reference counting, it seemed only reasonable that what I
> was returned would be a valid reference, and not just a copy of a pointer.
> There seems no reason why there should be any assumption that the
> SSL_SESSION lifespan sits within the SSL structure - it's an object with a
> reference count!
If SSL_get_session was a newly invented function, it should increase
the reference count. Unfortunately, it already exists and has a
different behaviour.
> Now why an SSL can't have a reference count higher than one, and be
> relevant to multiple threads each wanting a safe reference to it is beyond
> me.
There's no locking done for accesses on SSL structures. Unlike with
standard Unix file descriptors you cannot have one thread read and
another thread write at the same time, or have multiple threads read
at the same time or something like that, so it's best not to give the
SSL pointer to more than one thread in the first place.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
