Re: Function naming convention.
Arne Ansper wrote: one question: do we need those _peek_ functions at all? i think not. and i have a proposal how to keep new library and applications clean and keep compatibility with older applications: Well not everything has a reference count and not everything is static. Some of the calls instead return a copy of the structure. If you do this with everything that doesn't have a reference count you end up with lots of needless Malloc() functions and you also have problems writing a compatability wrapper because if you free the copy its gone. I suppose you could add reference counts to everything but each one can have a mutex operation associated with it and calling a mutex whenever any kind of 'get' operation is needed even when you know there will never be any kind of race condition is inefficient. [side note the library only uses a small number of mutexes: for example when you call X509_free(x) it uses a global lock for X509 instead of one for the 'x' structure] Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: [EMAIL PROTECTED] Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: [EMAIL PROTECTED] PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Function naming convention.
At 08:00 11.01.00 +0200, Arne Ansper wrote: So any preferences or alternative suggestions? peek for iget and copy for rget peek is OK. copy is bad, suggesting you get a independent copy you can modify. link(ed) ? By Goetz -- Goetz Babin-Ebell, TC TrustCenter GmbH, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Function naming convention.
On Tue, 11 Jan 2000, Richard Levitte - VMS Whacker wrote: [edit] - -Otherwise, I must say that I personally would like things to Become -Right rather than keeping Bug Compatibility, if one has to choose. So -I'd choose to put correctly updated and used reference counters -everywhere (or at least where it's relevant). - -Yes, there will be some struggle with old code that will break, but I -think that the future will look better with better consistency. I usually keep my mouth shut on this list but this is something important! :) Richard is completely and utterly correct. Make the changes to get this done right the first time instead of propagating these problems forward into a growing install base. Do it now rather than later! I believe it is more important to have a consistent API going into version 1.0.0 and to break binary compatibility now than to have to constantly watch out for (and explain to every new developer) the quirks in the code. Derek -- Derek Browne [EMAIL PROTECTED] Software Developer - Transport/Security Toronto, Ontario, Canada Hummingbird Communications Ltd. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Function naming convention.
On Tue, 11 Jan 2000, Richard Levitte - VMS Whacker wrote: [edit] - -Otherwise, I must say that I personally would like things to Become -Right rather than keeping Bug Compatibility, if one has to choose. So -I'd choose to put correctly updated and used reference counters -everywhere (or at least where it's relevant). - -Yes, there will be some struggle with old code that will break, but I -think that the future will look better with better consistency. I usually keep my mouth shut on this list but this is something important! :) Richard is completely and utterly correct. Make the changes to get this done right the first time instead of propagating these problems forward into a growing install base. Do it now rather than later! I believe it is more important to have a consistent API going into version 1.0.0 and to break binary compatibility now than to have to constantly watch out for (and explain to every new developer) the quirks in the code. I think Derek means breaking "source compatibility". But regardless, I am in agreement as well. In September the RSA patent in the United States expires. This is going to result in a significant increase in the number of commercial applications within the U.S. that are going to integrate OpenSSL into their code base. If I could help you fix this code I could. Perhaps the law will change on the 17th, perhaps not. But in any case, the code must be fixed now before the patent expires. The combination of the patent expiration and the expected relaxation of U.S. export law with regards to imported Open Source crypto libraries is going to open the flood gates to operating systems and applications that ship OpenSSL. Better to fix it before that happens then need to deal with all the weird behaviors especially in light of the lack of documentation on which functions must be handled in which way. Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 The Kermit Project * Columbia University 612 West 115th St #716 * New York, NY * 10025 http://www.kermit-project.org/k95.html * [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Function naming convention.
Dj Browne wrote: On Tue, 11 Jan 2000, Richard Levitte - VMS Whacker wrote: [edit] - -Otherwise, I must say that I personally would like things to Become -Right rather than keeping Bug Compatibility, if one has to choose. So -I'd choose to put correctly updated and used reference counters -everywhere (or at least where it's relevant). - -Yes, there will be some struggle with old code that will break, but I -think that the future will look better with better consistency. I usually keep my mouth shut on this list but this is something important! :) Richard is completely and utterly correct. Make the changes to get this done right the first time instead of propagating these problems forward into a growing install base. Do it now rather than later! I believe it is more important to have a consistent API going into version 1.0.0 and to break binary compatibility now than to have to constantly watch out for (and explain to every new developer) the quirks in the code. 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. Any code that relies on the old behaviour will end up leaking memory all over the place. 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 :-) So the alternative is to have a naming convention and just say the old functions are retained for backwards compatibility. Any future documentation might not even document the old functions to encourage the use of the new versions. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: [EMAIL PROTECTED] Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: [EMAIL PROTECTED] PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Function naming convention.
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. Any code that relies on the old behaviour will end up leaking memory all over the place. 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 :-) So the alternative is to have a naming convention and just say the old functions are retained for backwards compatibility. Any future documentation might not even document the old functions to encourage the use of the new versions. So in other words you plan to implement two versions of every single function? And then leave it up to the caller to determine what the behavior should be? This is going to be a nightmare. I would rather you just break the code outright. Forget the separate names. If you need to provide a method for determining whether or not the returned value should be considered persistent then add a parameter to the function specification which will determine the behavior. 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. 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. 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. Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 The Kermit Project * Columbia University 612 West 115th St #716 * New York, NY * 10025 http://www.kermit-project.org/k95.html * [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Function naming convention.
Jeffrey Altman wrote: So in other words you plan to implement two versions of every single function? And then leave it up to the caller to determine what the behavior should be? This is going to be a nightmare. I'm not sure what you mean by that. What we could have is one "official" version in the cases where it isn't apparent what is returned from context. For example when a pointer is returned it isn't obvious if it is persistent. If (for example) an int is returned or used then there is no ambiguity. The older versions could be retained for now but no guarantee that they always will be. Nothing is certain yet. I'm beginning to think the whole idea should be scrapped in favour of retaining the ambiguity but documenting it. I'd love to have the freedom to break existing code all over the place. The first thing I'd dump would be EVP probably followed closely behind by the ASN1 stuff. Unfortunately there is quite a large code base dependent on the current behaviour. Minor changes to the API can be accommodated: something that forces all existing code to be rewritten would be IMHO hard to justify. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: [EMAIL PROTECTED] Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: [EMAIL PROTECTED] PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Function naming convention.
So any preferences or alternative suggestions? peek for iget and copy for rget I like the peek thing, but "copy" is not a perfect choice of words: [...] Also note that we need a convention not just for "get" functions, there are also "set" functions. SSL_CTX_set_tmp_dh and SSL_CTX_set_tmp_rsa (macros actually, not functions) behave differently, and this should reflect in the names. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Function naming convention.
Arne Ansper [EMAIL PROTECTED]: So any preferences or alternative suggestions? peek for iget and copy for rget I like the peek thing, but "copy" is not a perfect choice of words: There's a difference between really copying a structure on the one hand and just providing another pointer and a reference count on the other hand. When a structure is copied, you can change values without interfering with the owners of other copies; not so if just a reference count is incremented. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Function naming convention.
jaltman I would rather you just break the code outright. Forget the separate jaltman names. If you need to provide a method for determining whether or not jaltman the returned value should be considered persistent then add a jaltman parameter to the function specification which will determine the jaltman behavior. I don't think Stephen meant that the old names would be meantioned any more, just that they would be present in dynamic libraries so old programs do not just wither and die suddenly... If they would be mentioned at all, they should be surrounded with a #ifdef OLD_OPENSSL..#endif or something similar. Another idea is to simply start with new names and toss the old ones. Sure, that will break some code, but at least it will be visible at once! But perhaps that's exactly what you mean... We could possibly offer to provide a name conversion script with warnings about what needs to be changed around each function call that has changed drastically enough to need calls to free up memory. -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-161 43 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis -- [EMAIL PROTECTED] Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Function naming convention.
[edit] - -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. - [edit] The changes should be done now, before v.1.0.0. By the time 1.0.0 arrives the API should be in such a state as to bring tears to the eye of the strictest of programmers. So maybe 0.9.5 should arrive on schedule and the API revolution occurs for 0.9.6? derek ps. I too, applaude the work of the openssl dev team...especially for the pay they get! :) -- Derek Browne [EMAIL PROTECTED] Software Developer - Transport/Security Toronto, Ontario, Canada Hummingbird Communications Ltd. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Function naming convention.
From: Geoff Thorpe [EMAIL PROTECTED]
geoff plenty of *_copy() functions to deal with that ('twould seem that a copy
geoff ups the reference count on the new structure by definition so copy
geoff functions needn't have any form of switch between "r" and/or "i").
I'm not sure if that parenthesis is telling the current state of
affairs or how it should be. If it's the latter, the new copy of any
structure should get a reference count of 1 and nothing else. The
reason should be obvious.
--
Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED]
Redakteur@Stacken \ S-161 43 BROMMA \ T: +46-8-26 52 47
\ SWEDEN \ or +46-708-26 53 44
Procurator Odiosus Ex Infernis -- [EMAIL PROTECTED]
Unsolicited commercial email is subject to an archival fee of $400.
See http://www.stacken.kth.se/~levitte/mail/ for more info.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: Function naming convention.
From: Geoff Thorpe [EMAIL PROTECTED]
geoff On Tue, 11 Jan 2000, Richard Levitte - VMS Whacker wrote:
geoff
geoff From: Geoff Thorpe [EMAIL PROTECTED]
geoff
geoff geoff plenty of *_copy() functions to deal with that ('twould seem that a
copy
geoff geoff ups the reference count on the new structure by definition so copy
geoff geoff functions needn't have any form of switch between "r" and/or "i").
geoff
geoff I'm not sure if that parenthesis is telling the current state of
geoff affairs or how it should be. If it's the latter, the new copy of any
geoff structure should get a reference count of 1 and nothing else. The
geoff reason should be obvious.
geoff
geoff The "by definition" bit was supposed to indicate what you have described.
Ah. It was the "ups the reference cont" that made it confusing...
--
Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED]
Redakteur@Stacken \ S-161 43 BROMMA \ T: +46-8-26 52 47
\ SWEDEN \ or +46-708-26 53 44
Procurator Odiosus Ex Infernis -- [EMAIL PROTECTED]
Unsolicited commercial email is subject to an archival fee of $400.
See http://www.stacken.kth.se/~levitte/mail/ for more info.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
RE: Function naming convention.
I agree. It's not as if developers HAVE to take the latest release. If 0.9.5 were a maintenance release (and 0.9.6, etc), then developers using the 0.9.X branch will not be disadvantaged. At the same time, I see real advantages to starting 1.0.0 with a new API. The functions could behave predictably and would be easier to document. Architectural changes could also be contemplated (removal of EVP?). My $0.02. Ron. -Original Message- From: Dj Browne [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 12, 2000 9:21 AM To: [EMAIL PROTECTED] Subject: Re: Function naming convention. [edit] - -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. - [edit] The changes should be done now, before v.1.0.0. By the time 1.0.0 arrives the API should be in such a state as to bring tears to the eye of the strictest of programmers. So maybe 0.9.5 should arrive on schedule and the API revolution occurs for 0.9.6? derek ps. I too, applaude the work of the openssl dev team...especially for the pay they get! :) -- Derek Browne [EMAIL PROTECTED] Software Developer - Transport/Security Toronto, Ontario, Canada Hummingbird Communications Ltd. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Function naming convention.
So any preferences or alternative suggestions? peek for iget and copy for rget arne __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
