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
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,
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
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
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
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
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"
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
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
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
[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
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
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
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
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]
15 matches
Mail list logo