Hi there,
On Tue, 11 Jan 2000, Jeffrey Altman wrote:
> > The problem here is what is right?
> >
> > Its not that clear cut.
> >
> > If we decide that all the get/set/add functions should up reference
> > counts then you have to add reference counts to all manner of things or
> > Malloc() copies.
reference counts should really be for allowing multiple references to the
*same* data with the theory that if all obtained references are
subsequently free'd, the real cleanup takes place with the last *_free()
call only. I don't think this should get further muddied with ambiguity
over whether it's the same structure or a new copy - there seems to be
plenty of *_copy() functions to deal with that ('twould seem that a copy
ups the reference count on the new structure by definition so copy
functions needn't have any form of switch between "r" and/or "i").
> > Any code that relies on the old behaviour will end up leaking memory all
> > over the place.
>
Old code shouldn't be compiled with newer versions under the blind
assumption that nothing has changed (the behaviour has been changing in
lots of various subtle and other ways). Perhaps a version change is
required to keep people happy - its easy to see people getting stroppy
compiling 0.9.4-compatible apps with 0.9.5 and having things blow up. But
if it blows up with 1.0.0 (and 1.0.0 has a big note saying "check the
following things in your code!!!") then I think it's reasonable enough.
Last time I checked, 0.9.5's own applications compiled but in some cases
didn't work as expected because of behavioural changes.
> > Alternatively if we decide that nothing should up reference counts then
> > anything which assumes that the structure is persistent will crash when
> > one of them gets freed.
> >
> > Doing either will break lots of existing code need major rewrites and
> > probably get several of us lynched :-)
Not if 0.9.4-stable (and others) are still available for download and
0.9.5 (or whatever) has a note telling people not to blindly assume
backward compatibility - it would be a reasonable assumption if the only
work being done was bug-fixing but that *really* isn't the case.
>
> This will cause all existing source code to break. And that is a good
> thing because more than like most current applications are leaking
> memory all over the place or a crashing under certain circumstances
> that appear random and can rarely be replicated.
Yup. Fixing up legacy code to work with a more logical API is a much
lesser evil than having half the legacy code still exposed (possibly) to
NYSINYD bugs (now-you-see-it, now-you-don't) and all new programming
requiring developers to disect the openssl source (and consult their
horoscopes) to know which calls to make, when to make them, and how.
> Breaking the interfaces will force the developers to examine their
> code to see how they are managing the memory to ensure they are doing
> it properly. The way things are now every time there has been a new
> OpenSSL (or SSLeay) release I have had to spend three or four days
> going over the code to make sure things still work anyway. I don't
> see this requirement going away with the 0.9.5 release because of the
> desire to clutter the API with the intention of preserving backwards
> compatibility.
Me too - my startup code does a few tests to see whether the openssl
library being compiled against does or does not alter reference counts
with certain calls. It then sets flags used at run-time to make sure I
manually [in|de]crement reference counts when the library doesn't. This is
the only way I can program in a way consistent with the idea of "reference
counting" without patching OpenSSL itself or writing a "clean" wrapper
around the existing API. Dr Henson has been doing great things with the
X509 code (verifying particularly) and I look forward to 0.9.5 but I know
full well that I'm going to have to go through my debugging dance again to
make sure I'm making the right calls at the right time. This is no fault
of the current developers, I've seen what they're working with! ... So
clutering the API further for the sake of "compatibility" is IMHO rather
pointless.
>
> If you want to preserve backwards compatibility with my recommendation
> then you can do it via the use of an #ifdef section in the header
> which will map the old parameter lists to the new ones. But by
> default this functionality should be disabled.
or perhaps a shell script to the effect of;
#!/bin/sh
lynx http://www.openssl.org/download/old_versions
:-)
Cheers,
Geoff
----------------------------------------------------------------------
Geoff Thorpe Email: [EMAIL PROTECTED]
Cryptographic Software Engineer, C2Net Europe http://www.int.c2.net
----------------------------------------------------------------------
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
