Re: [openssl.org #85] 0.9.7 prototype constification problems
On Mon, Jun 17, 2002 at 07:02:45PM +0100, Ben Laurie wrote: Avery Pennarun via RT wrote: On Mon, Jun 17, 2002 at 11:19:31AM +0200, Bodo Moeller wrote: Good question, but this problem does not appear to apply to C, and anyway it only makes *existing* code uglier -- for new code, the modified API makes more sense (the encoded data can be in 'const unsigned char' arrays all the time). If you don't want #ifdefs and casts throughout your code, please consider hiding this in wrapper functions. Hmm, okay, I'm not really convinced, but now that I see it doesn't cause C programs to not compile, I think it's okay to accept the small number of openssl-using C++ programs that will need changes because of this. Hmm, well, I'm not, because all right-thinking projects have a zero-warnings policy. OpenSSL included. The old API is not perfect when the data is located in a 'const' array, the new API is not perfect when the data is located in a non-'const' array. C++ code can be written to match either the old or the new API; with the wrong API, you can have either zero warnings or zero casts, not both. As those functions are not really supposed to modify the data, the 'const' variant appears to be the right one. -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #85] 0.9.7 prototype constification problems
Bodo Moeller wrote: On Mon, Jun 17, 2002 at 07:02:45PM +0100, Ben Laurie wrote: Avery Pennarun via RT wrote: On Mon, Jun 17, 2002 at 11:19:31AM +0200, Bodo Moeller wrote: Good question, but this problem does not appear to apply to C, and anyway it only makes *existing* code uglier -- for new code, the modified API makes more sense (the encoded data can be in 'const unsigned char' arrays all the time). If you don't want #ifdefs and casts throughout your code, please consider hiding this in wrapper functions. Hmm, okay, I'm not really convinced, but now that I see it doesn't cause C programs to not compile, I think it's okay to accept the small number of openssl-using C++ programs that will need changes because of this. Hmm, well, I'm not, because all right-thinking projects have a zero-warnings policy. OpenSSL included. The old API is not perfect when the data is located in a 'const' array, the new API is not perfect when the data is located in a non-'const' array. C++ code can be written to match either the old or the new API; with the wrong API, you can have either zero warnings or zero casts, not both. As those functions are not really supposed to modify the data, the 'const' variant appears to be the right one. Fair enough. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #85] 0.9.7 prototype constification problems
Avery Pennarun [EMAIL PROTECTED]: On Thu, Jun 13, 2002 at 01:26:42PM +0200, Bodo Moeller via RT wrote: [[EMAIL PROTECTED] - Thu Jun 6 18:39:34 2002]: It appears the openssl guys goofed in 0.97beta. The prototype for the d2i_RSAPrivateKey function in 0.9.6c, which I use, is like this: d2i_RSAPrivateKey(RSA **a, unsigned char **pp, long length); ie., without a const on the second parameter. The const should have been done like this (I think): const unsigned char * const *pp ...which would be entirely backwards-compatible with old versions of openssl. Could you explain why you think this would improve compatibility (compared with 'const unsigned char **pp', which is how 'pp' should be declared in 0.9.7-beta1, although the exact definition is hidden behind macros)? Any variable that could be passed to a function taking unsigned char ** could also be passed to a function taking const unsigned char * const *. Thus, using the above declaration would make openssl's api 100% source-compatible with previous versions, while promising an increased level of constness. Using const unsigned char **, however, is not 100% api-compatible, because you can't safely pass an unsigned char ** to it, for complicated reasons explained in the URL I sent earlier. [http://www.geocrawler.com/archives/3/362/1997/9/0/2036587/] I see, so this is an C++ speciality. As far as C is concerned, the types should be incompatible between any of these three variants, but compilers tend not to look that close (and otherwise you'd use a cast). Writing code that tries to change a 'const char' object as shown at the above URL is possible -- the actual assignment is illegal, but in general the compiler cannot catch this. In fact the second 'const' would be wrong because the pointer that 'pp' points to is updated to reflect how much of the encoded data has been processed by the d2i_... function. I.e., it is not at all constant. Now, you caught me there. The change I proposed earlier (adding an additional const) would fix API compatibility, but promises a level of constness that you're not actually providing. Unfortunately, I don't know a way around it: the problem is that the beta1 level of constness looks right, but doesn't _actually_ promise the constness that it looks like it does, due to the crazy hackery described in the URL I sent earlier. Prototypes alone don't really guarantee constness anyway. If a function is passed a 'const int *' pointer and knows somehow that the object pointed to is not 'const' (i.e. the pointer was 'int *' originally), it may cast the pointer back to 'int *' and modify the object. It also makes the API incompatible with older versions. I can't pass the address of unsigned char *p to the new function. I guess you'll have to include a cast to the new type depending on the value of OPENSSL_VERSION_NUMBER. I know this is ugly, but I don't think we should un-constify the prototype to avoid such problems. (In fact we'll have to make various other prototype changes to clean up the API, for example 'int' quite often should be 'size_t' etc.) -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #85] 0.9.7 prototype constification problems
On Sat, Jun 15, 2002 at 12:14:00PM +0200, Bodo Moeller wrote: Using const unsigned char **, however, is not 100% api-compatible, because you can't safely pass an unsigned char ** to it, for complicated reasons explained in the URL I sent earlier. [http://www.geocrawler.com/archives/3/362/1997/9/0/2036587/] I see, so this is an C++ speciality. As far as C is concerned, the types should be incompatible between any of these three variants, but compilers tend not to look that close (and otherwise you'd use a cast). Writing code that tries to change a 'const char' object as shown at the above URL is possible -- the actual assignment is illegal, but in general the compiler cannot catch this. I don't understand why you say this is C++-specific: I think C does const in the same way. My original suggestion (two consts) is not incompatible with either of the others, it just promises a level of constness that you're not actually going to provide. Unfortunately, I don't know a way around it: the problem is that the beta1 level of constness looks right, but doesn't _actually_ promise the constness that it looks like it does, due to the crazy hackery described in the URL I sent earlier. Prototypes alone don't really guarantee constness anyway. If a function is passed a 'const int *' pointer and knows somehow that the object pointed to is not 'const' (i.e. the pointer was 'int *' originally), it may cast the pointer back to 'int *' and modify the object. Prototypes are really just a clue for the user and implementer of a class: a program would run exactly the same if const were globally #defined to be meaningless. If you're not concerned about what you promise the user (and a good comment above the prototype can repair that promise anyway) then use my original suggestion const unsigned char * const * which will happily accept parameters of any of these types: unsigned char ** const unsigned char ** const unsigned char * const * ...and then typecast it _yourself_ inside the function. This maintains API compatibility and lets you pass const unsigned char ** objects, which is what you presumably wanted. It also makes the API incompatible with older versions. I can't pass the address of unsigned char *p to the new function. I guess you'll have to include a cast to the new type depending on the value of OPENSSL_VERSION_NUMBER. I know this is ugly, but I don't think we should un-constify the prototype to avoid such problems. Oh, argh, no! Please, please don't do this. So far we've managed to avoid all such things and wvstreams goes back to quite old revs of openssl. What's the point of an api cleanup that makes user code uglier? (In fact we'll have to make various other prototype changes to clean up the API, for example 'int' quite often should be 'size_t' etc.) This might produce warnings, but never errors, I think. Have fun, Avery __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #85] 0.9.7 prototype constification problems
Avery Pennarun [EMAIL PROTECTED]: On Thu, Jun 13, 2002 at 01:26:42PM +0200, Bodo Moeller via RT wrote: [[EMAIL PROTECTED] - Thu Jun 6 18:39:34 2002]: It appears the openssl guys goofed in 0.97beta. The prototype for the d2i_RSAPrivateKey function in 0.9.6c, which I use, is like this: d2i_RSAPrivateKey(RSA **a, unsigned char **pp, long length); ie., without a const on the second parameter. The const should have been done like this (I think): const unsigned char * const *pp ...which would be entirely backwards-compatible with old versions of openssl. Could you explain why you think this would improve compatibility (compared with 'const unsigned char **pp', which is how 'pp' should be declared in 0.9.7-beta1, although the exact definition is hidden behind macros)? Any variable that could be passed to a function taking unsigned char ** could also be passed to a function taking const unsigned char * const *. Thus, using the above declaration would make openssl's api 100% source-compatible with previous versions, while promising an increased level of constness. Using const unsigned char **, however, is not 100% api-compatible, because you can't safely pass an unsigned char ** to it, for complicated reasons explained in the URL I sent earlier. [http://www.geocrawler.com/archives/3/362/1997/9/0/2036587/] I see, so this is an C++ speciality. As far as C is concerned, the types should be incompatible between any of these three variants, but compilers tend not to look that close (and otherwise you'd use a cast). Writing code that tries to change a 'const char' object as shown at the above URL is possible -- the actual assignment is illegal, but in general the compiler cannot catch this. In fact the second 'const' would be wrong because the pointer that 'pp' points to is updated to reflect how much of the encoded data has been processed by the d2i_... function. I.e., it is not at all constant. Now, you caught me there. The change I proposed earlier (adding an additional const) would fix API compatibility, but promises a level of constness that you're not actually providing. Unfortunately, I don't know a way around it: the problem is that the beta1 level of constness looks right, but doesn't _actually_ promise the constness that it looks like it does, due to the crazy hackery described in the URL I sent earlier. Prototypes alone don't really guarantee constness anyway. If a function is passed a 'const int *' pointer and knows somehow that the object pointed to is not 'const' (i.e. the pointer was 'int *' originally), it may cast the pointer back to 'int *' and modify the object. It also makes the API incompatible with older versions. I can't pass the address of unsigned char *p to the new function. I guess you'll have to include a cast to the new type depending on the value of OPENSSL_VERSION_NUMBER. I know this is ugly, but I don't think we should un-constify the prototype to avoid such problems. (In fact we'll have to make various other prototype changes to clean up the API, for example 'int' quite often should be 'size_t' etc.) -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #85] 0.9.7 prototype constification problems
On Sat, Jun 15, 2002 at 12:14:00PM +0200, Bodo Moeller wrote: Using const unsigned char **, however, is not 100% api-compatible, because you can't safely pass an unsigned char ** to it, for complicated reasons explained in the URL I sent earlier. [http://www.geocrawler.com/archives/3/362/1997/9/0/2036587/] I see, so this is an C++ speciality. As far as C is concerned, the types should be incompatible between any of these three variants, but compilers tend not to look that close (and otherwise you'd use a cast). Writing code that tries to change a 'const char' object as shown at the above URL is possible -- the actual assignment is illegal, but in general the compiler cannot catch this. I don't understand why you say this is C++-specific: I think C does const in the same way. My original suggestion (two consts) is not incompatible with either of the others, it just promises a level of constness that you're not actually going to provide. Unfortunately, I don't know a way around it: the problem is that the beta1 level of constness looks right, but doesn't _actually_ promise the constness that it looks like it does, due to the crazy hackery described in the URL I sent earlier. Prototypes alone don't really guarantee constness anyway. If a function is passed a 'const int *' pointer and knows somehow that the object pointed to is not 'const' (i.e. the pointer was 'int *' originally), it may cast the pointer back to 'int *' and modify the object. Prototypes are really just a clue for the user and implementer of a class: a program would run exactly the same if const were globally #defined to be meaningless. If you're not concerned about what you promise the user (and a good comment above the prototype can repair that promise anyway) then use my original suggestion const unsigned char * const * which will happily accept parameters of any of these types: unsigned char ** const unsigned char ** const unsigned char * const * ...and then typecast it _yourself_ inside the function. This maintains API compatibility and lets you pass const unsigned char ** objects, which is what you presumably wanted. It also makes the API incompatible with older versions. I can't pass the address of unsigned char *p to the new function. I guess you'll have to include a cast to the new type depending on the value of OPENSSL_VERSION_NUMBER. I know this is ugly, but I don't think we should un-constify the prototype to avoid such problems. Oh, argh, no! Please, please don't do this. So far we've managed to avoid all such things and wvstreams goes back to quite old revs of openssl. What's the point of an api cleanup that makes user code uglier? (In fact we'll have to make various other prototype changes to clean up the API, for example 'int' quite often should be 'size_t' etc.) This might produce warnings, but never errors, I think. Have fun, Avery __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #85] 0.9.7 prototype constification problems
On Thu, Jun 13, 2002 at 01:26:42PM +0200, Bodo Moeller via RT wrote: [[EMAIL PROTECTED] - Thu Jun 6 18:39:34 2002]: It appears the openssl guys goofed in 0.97beta. The prototype for the d2i_RSAPrivateKey function in 0.9.6c, which I use, is like this: d2i_RSAPrivateKey(RSA **a, unsigned char **pp, long length); ie., without a const on the second parameter. The const should have been done like this (I think): const unsigned char * const *pp ...which would be entirely backwards-compatible with old versions of openssl. Could you explain why you think this would improve compatibility (compared with 'const unsigned char **pp', which is how 'pp' should be declared in 0.9.7-beta1, although the exact definition is hidden behind macros)? Any variable that could be passed to a function taking unsigned char ** could also be passed to a function taking const unsigned char * const *. Thus, using the above declaration would make openssl's api 100% source-compatible with previous versions, while promising an increased level of constness. Using const unsigned char **, however, is not 100% api-compatible, because you can't safely pass an unsigned char ** to it, for complicated reasons explained in the URL I sent earlier. In fact the second 'const' would be wrong because the pointer that 'pp' points to is updated to reflect how much of the encoded data has been processed by the d2i_... function. I.e., it is not at all constant. Now, you caught me there. The change I proposed earlier (adding an additional const) would fix API compatibility, but promises a level of constness that you're not actually providing. Unfortunately, I don't know a way around it: the problem is that the beta1 level of constness looks right, but doesn't _actually_ promise the constness that it looks like it does, due to the crazy hackery described in the URL I sent earlier. It also makes the API incompatible with older versions. I can't pass the address of unsigned char *p to the new function. On the other hand, I can't pass the address of const unsigned char *p to the old-style function. Neither situation is desirable... but it looks like you might have to just use two different functions with two different APIs, unfortunately. I don't know another way out. Have fun, Avery __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #85] 0.9.7 prototype constification problems
On Thu, Jun 13, 2002 at 01:26:42PM +0200, Bodo Moeller via RT wrote: [[EMAIL PROTECTED] - Thu Jun 6 18:39:34 2002]: It appears the openssl guys goofed in 0.97beta. The prototype for the d2i_RSAPrivateKey function in 0.9.6c, which I use, is like this: d2i_RSAPrivateKey(RSA **a, unsigned char **pp, long length); ie., without a const on the second parameter. The const should have been done like this (I think): const unsigned char * const *pp ...which would be entirely backwards-compatible with old versions of openssl. Could you explain why you think this would improve compatibility (compared with 'const unsigned char **pp', which is how 'pp' should be declared in 0.9.7-beta1, although the exact definition is hidden behind macros)? Any variable that could be passed to a function taking unsigned char ** could also be passed to a function taking const unsigned char * const *. Thus, using the above declaration would make openssl's api 100% source-compatible with previous versions, while promising an increased level of constness. Using const unsigned char **, however, is not 100% api-compatible, because you can't safely pass an unsigned char ** to it, for complicated reasons explained in the URL I sent earlier. In fact the second 'const' would be wrong because the pointer that 'pp' points to is updated to reflect how much of the encoded data has been processed by the d2i_... function. I.e., it is not at all constant. Now, you caught me there. The change I proposed earlier (adding an additional const) would fix API compatibility, but promises a level of constness that you're not actually providing. Unfortunately, I don't know a way around it: the problem is that the beta1 level of constness looks right, but doesn't _actually_ promise the constness that it looks like it does, due to the crazy hackery described in the URL I sent earlier. It also makes the API incompatible with older versions. I can't pass the address of unsigned char *p to the new function. On the other hand, I can't pass the address of const unsigned char *p to the old-style function. Neither situation is desirable... but it looks like you might have to just use two different functions with two different APIs, unfortunately. I don't know another way out. Have fun, Avery __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #85] 0.9.7 prototype constification problems
[[EMAIL PROTECTED] - Thu Jun 6 18:39:34 2002]: [...] It appears the openssl guys goofed in 0.97beta. The prototype for the d2i_RSAPrivateKey function in 0.9.6c, which I use, is like this: d2i_RSAPrivateKey(RSA **a, unsigned char **pp, long length); ie., without a const on the second parameter. The const should have been done like this (I think): const unsigned char * const *pp ...which would be entirely backwards-compatible with old versions of openssl. Could you explain why you think this would improve compatibility (compared with 'const unsigned char **pp', which is how 'pp' should be declared in 0.9.7-beta1, although the exact definition is hidden behind macros)? In fact the second 'const' would be wrong because the pointer that 'pp' points to is updated to reflect how much of the encoded data has been processed by the d2i_... function. I.e., it is not at all constant. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Constification
On Wed, Nov 08, 2000 at 07:34:33AM -0800, Geoff Thorpe wrote: [...] whose internals are generally only managed inside OpenSSL anyway. Eg. the caller may pass a const X509* pointer, but the caller is generally not supposed to be using the structure's internals directly anyway - the use of "const" is 80% for the application programmer's own benefit, whether we violate it or not. A problem is that if the API says the argument is 'const', then it looks as if it's safe to use the same object in multiple threads concurrently. For X509_cmp it is actually safe because CRYPTO_LOCK_X509 is used if necessary, but we cannot do something like this for BN_mul. -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Constification buglet in crypto/bn/bn_asm.c
The BN_LLONG version of bn_add_words() didn't get constified in the recent
changes, so it isn't consistent with its prototype. This is fixed by the
patch below.
/Krister
--- openssl-SNAP-20001117/crypto/bn/bn_asm.c.bakFri Nov 17 00:00:26 2000
+++ openssl-SNAP-20001117/crypto/bn/bn_asm.cFri Nov 17 23:02:29 2000
@@ -296,7 +296,7 @@
#endif /* !defined(BN_LLONG) defined(BN_DIV2W) */
#ifdef BN_LLONG
-BN_ULONG bn_add_words(BN_ULONG *r, BN_ULONG *a, BN_ULONG *b, int n)
+BN_ULONG bn_add_words(BN_ULONG *r, const BN_ULONG *a, const BN_ULONG *b, int n)
{
BN_ULLONG ll=0;
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: Constification
%% Ben Laurie [EMAIL PROTECTED] writes: bl "Paul D. Smith" wrote: It's worse than that: you have to provide two different data structures internally. Unless you're going to cast internally, and if so why bother to have two API's anyway? It quickly reaches the point of ridiculousness :). bl There's sense in internal casting because you know that you can bl carefully engineer it so that it doesn't actaully do anything bl untoward. Well, what I meant was this: the reason (I infer) that you don't like the strstr()-style interface is that it "legalizes" a way to remove const from a value, without explicitly casting. The argument goes that for programmers who aren't sufficiently careful, this can lead to errors (which point, BTW, I do agree with--but C has never been a language that programmers who aren't sufficiently careful should be using--C is a knife; if you want a spoon try Pascal). What I'm saying is that in order to truly preserve the constness of values for the lhash API, you'd need separate data structures as well as separate function calls. If you don't have that, you can easily put const data into lhash using the const function and get it out using the non-const call, leading to the same "legal" removal of constness, just at a distance (which, I think, is even worse). If you reject the notion of different data structures, which I think we can all agree would be totally ridiculous, then there's no reason to have two API's in the first place; you might as well just leave it simple with one API. Or, avoid the const altogether, but I think lhash really is an appropriate place for constification. bl But I'll freely admit that this is probably an API too far in bl lhash's case. I think we're in violent agreement :). I also think this horse is getting very close to powdered form. -- --- Paul D. Smith [EMAIL PROTECTED]HASMAT--HA Software Methods Tools "Please remain calm...I may be mad, but I am a professional." --Mad Scientist --- These are my opinions---Nortel Networks takes no responsibility for them. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Constification
From: Geoff Thorpe [EMAIL PROTECTED] Hi there, [snip] psmith IMHO this is a legitimate reason to cast away const, and that psmith the "const" notation on the arguments to lhash is useful for psmith self-documentation purposes, at the least. Hmm, perhaps you're right. I'm just a bit worried about how hard it might become if someone is stupid enough to actually use the returned (non-const) pointer to change something that is on RO memory... Exactly. Well, if I'm not mistaken - none of the current changes should involve returning non-consts pointers to const memory, and that is not even the issue at hand: in fact it's quite the opposite. The issue *is* (again, if I'm not mistaken) that we want the exposed API to be locked up a bit tighter with in-values being declared as "const" where in any sane world they should be (and thus, application programmers can benefit from the discipline that brings back into their own compilation checking) even though OpenSSL itself is in certain weird ways sometimes modifying what that "const" parameter was referring to. Bear in mind also that in *all* [snip] A clear and concise explanation for the justification of constifying the library - the API exposed to the applications programmer. What the library does internally with the memory should have no affect upon the calling application's state. If the function expects a const pointer, I will provide one and assume the buffer will not become "tainted" by the function on return. Should the function return a const pointer, I will not modify the contents pointed to by it. Viewed in this light, const is a form of contract between caller and callee. I know this is elementary to the readers of this mail group. My point is that if the constification can be made to the exposed APIs without causing undo performance degradation or code breakage then I'm for it. Even if only half of the exposed function parameters can be constifyed then that is at least self-documenting code which helps those of us from an "older" generation who's arms get sore continually reaching for API specifications because our neural memory banks are full . Thanks! ;-) __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Constification
%% Ben Laurie [EMAIL PROTECTED] writes: Are you saying you just don't use const, or that you provide two different functions or two interfaces to the same function? bl The latter. To me, that's much more ugly than simply casting it. This is C, not C++, and we do the best we can with what we have--but making two API's is not the right way to go. Maybe for BN, where (IIRC) you're just talking about one function and that function really _does_ write to the memory, it makes sense. For things like lhash, I vote "nay". bl The problem is that people modify something to be const and miss bl the fact that it got dropped by a library function, and so modify bl it. This is a PITA. IME, this rarely happens and is pretty straightforward to detect. If I'm missing something maybe you could provide an actual example of what you mean, say using the crypto/lhash/lhash.c:lh_insert() function. bl In the case of lhash the solution is tedious: provide two versions of bl the entire API, one for const data, one not. Whether this is worth the bl effort is debatable. It's worse than that: you have to provide two different data structures internally. Unless you're going to cast internally, and if so why bother to have two API's anyway? It quickly reaches the point of ridiculousness :). -- --- Paul D. Smith [EMAIL PROTECTED]HASMAT--HA Software Methods Tools "Please remain calm...I may be mad, but I am a professional." --Mad Scientist --- These are my opinions---Nortel Networks takes no responsibility for them. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Constification
"Paul D. Smith" wrote: %% Ben Laurie [EMAIL PROTECTED] writes: Are you saying you just don't use const, or that you provide two different functions or two interfaces to the same function? bl The latter. To me, that's much more ugly than simply casting it. This is C, not C++, and we do the best we can with what we have--but making two API's is not the right way to go. Maybe for BN, where (IIRC) you're just talking about one function and that function really _does_ write to the memory, it makes sense. For things like lhash, I vote "nay". bl The problem is that people modify something to be const and miss bl the fact that it got dropped by a library function, and so modify bl it. This is a PITA. IME, this rarely happens and is pretty straightforward to detect. If I'm missing something maybe you could provide an actual example of what you mean, say using the crypto/lhash/lhash.c:lh_insert() function. bl In the case of lhash the solution is tedious: provide two versions of bl the entire API, one for const data, one not. Whether this is worth the bl effort is debatable. It's worse than that: you have to provide two different data structures internally. Unless you're going to cast internally, and if so why bother to have two API's anyway? It quickly reaches the point of ridiculousness :). There's sense in internal casting because you know that you can carefully engineer it so that it doesn't actaully do anything untoward. But I'll freely admit that this is probably an API too far in lhash's case. Cheers, Ben. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Constification
Richard Levitte - VMS Whacker wrote:
From: Ben Laurie [EMAIL PROTECTED]
ben Like strstr()...
ben
benbl Just because the C libraries are broken doesn't mean we should
benbl break ours. In Apache we fix these rather than live with them.
ben
ben How exactly do you fix them?
ben
ben By wrapping them with correctly declared functions.
So, either:
const char *correct_strstr(const char *s1, const char *s2)
{
return strstr(s1, s2);
}
or:
char *correct_strstr(char *s1, const char *s2)
{
return strstr(s1, s2);
}
Is that right? Both of those have problems. The first because you
can't manipulate the result even if the strings you gave from the
start are non-const, and the second because you can't give it a 'const
char *' as first argument...
No, you have two, a const and a non-const version.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: Constification
From: Ben Laurie [EMAIL PROTECTED] ben No, you have two, a const and a non-const version. Fine, I'll give it a shot. I do not believe in it, but I will. -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Chairman@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 Redakteur@Stacken \ SWEDEN \ or +46-709-50 36 10 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Software Engineer, Celo Communications: http://www.celocom.com/ 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: Constification
"Paul D. Smith" wrote: %% Ben Laurie [EMAIL PROTECTED] writes: bl By wrapping them with correctly declared functions. Are you saying you just don't use const, or that you provide two different functions or two interfaces to the same function? The latter. I don't think either of these two options is better than deconstifying in this particular commonly-used way. The fact is that C's const is not robust enough to handle all these cases, so we have to handle them by convention rather than compiler-imposed fiat. This convention is well-used and well-understood, and I believe the benefits outweigh the problems. The problem is that people modify something to be const and miss the fact that it got dropped by a library function, and so modify it. This is a PITA. lhash is a basic library, and if we say you can't store const data in lhash (without casting const away first) that's going to have a lot of ripple effect. If I'm missing something maybe you could provide an actual example of what you mean, say using the crypto/lhash/lhash.c:lh_insert() function. In the case of lhash the solution is tedious: provide two versions of the entire API, one for const data, one not. Whether this is worth the effort is debatable. Using C++ makes it much easier, of course. The problems in BN are much more severe; in my unconst'ing efforts in May I went down _exactly_ the same path Richard is going down, and was forced to back up and remove all the const'ing I'd done in BN for exactly the reasons we are discussing. In this case I agree with Ben that const means the function _cannot_, under _any_ circumstances, modify the const data. Either the function has to be rewritten to avoid that need, or it can't be made const. Exactly. Cheers, Ben. -- http://www.apache-ssl.org/ben.html "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Constification
With regards to this current discussion, has anyone given thought to the
fact that if the const string address being passed into a function with a
const typed parameter resides within a memory page marked as ReadOnly the
constified function will GP should it attempt to write to that page? I'm
not sure of the behavior of every OS or compiler optimization or memory
layout currently in existence but the const modifier means just that: the
const address given to a function points to memory that will not, ever, be
modified. Functions that need to make temporary modifications within such a
string must make a local copy first.
My .02 cents worth...
- Original Message -
From: Lutz Jaenicke [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, November 08, 2000 10:08 AM
Subject: Re: Constification
On Wed, Nov 08, 2000 at 04:01:13PM +0100, Richard Levitte - VMS Whacker
wrote:
So, either:
const char *correct_strstr(const char *s1, const char *s2)
{
return strstr(s1, s2);
}
or:
char *correct_strstr(char *s1, const char *s2)
{
return strstr(s1, s2);
}
Is that right? Both of those have problems. The first because you
can't manipulate the result even if the strings you gave from the
start are non-const, and the second because you can't give it a 'const
char *' as first argument...
HP-UX says:
char *strstr(const char *s1, const char *s2);
I read this: s1 and s2 are passed to strstr(). strstr() will not modify
the locations s1 and s2 are pointing to, so the optimizer may safely
assume that they have not been changed after the call to strstr().
That does not make any statement about what the calling function does
with s1 (and hence the return value _must_not_ be "const char *").
Sorry, couldn't resist :-)
Lutz
--
Lutz Jaenicke [EMAIL PROTECTED]
BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153
__
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: Constification
Hi there, I'm gonna spill my splein here because, just like Richard and Paul have done now and in the past, I have suffered at the hands of a well-meaning mission to constify parts of OpenSSL. On Wed, 8 Nov 2000, Ben Laurie wrote: Richard Levitte - VMS Whacker wrote: From: "Paul D. Smith" [EMAIL PROTECTED] psmith This is similar to standard C functions which take a const psmith char*, for example, and return a char* that points into the psmith string. Like strstr()... Just because the C libraries are broken doesn't mean we should break ours. In Apache we fix these rather than live with them. Apples and oranges, Apache is an application, OpenSSL is a library and API (that just happens to have applications in it). I know Apache has an "API" for writing modules, one that I'm rather painfully familiar with in fact, and I'd hardly call it an API designer's case study in encapsulation, let alone a worthwhile example of "const"ification. For starters, generally there is no illusion of binary compatibility maintained, and direct access to Apache structures is actively encouraged anyway. I've butted heads with this constification issue in the past too, and unfortunately sooner or later you follow the code-dependency trails into stuff like the ASN garbage where perfectly acceptable const logic fights tooth and nail against immovable macro casting sludge. Until such time as that sludge can be legitimately moved, I have to say that I think de-consting is not only acceptable but necessary - and whether or not we like it, it's already present in core componentry of OpenSSL. Normally, I'd agree that const means const, and that's the end of it (the RO memory issue being but one very good reason). However, in this particular situation that is simply not a pragmatic attitude to take. (a) OpenSSL already violates this, so systems that use real RO memory would *already* be a problem. (b) This will continue to be the case until the real cause of the problem(s) is(are) fixed. (c) The alternative is to declare virtually nothing as const, including return values. (d) The alternative (c) means that applications themselves that attempt to pass around various structures internally as "const" for discipline reasons either have to abandon the idea (and suffer the risks), or perform lots of risky deconstification in their own code every time they try to touch the OpenSSL API. So all the hand-wavey arguments about "const" being sacred and not to be violated (which under all other circumstances I'd completely agree with) aren't presently really worth a scrap of deleted right now. X509_cmp() is a case in point ... there's no guarantee that the ASN sludge won't actually modify the passed certs when doing the compare, yet to not declare X509_cmp() with const parameters filters *all* the way back out to the point where nothing at all (virtually) can be const. This in turn requires the API to virtually never use const and that starts to make writing applications more difficult because application programmers can't use ordinary programming principles (and protect themselves from themselves by using const wherever possible) because our API requires non-const all the time. Anyway, back to the case at hand: the BIGNUM code, IMHO, is in nearly as messy a state as the ASN code, and is equally responsible for const (and other normally clearcut design principle) weirdness. The "logic" (for want of a more accurate term) is extremely warped in many places, often opaque, and it is about as decentralised, uncoordinated, and utterly uncontrollable as any block of code I have ever seen that is supposed to (for the most part) simply manipulate one basic type. Try to imagine a BN_METHOD (as I have many times) and you'll see what I mean. Unfortunately, it is also a fundamental factor in OpenSSL's "performance", it has to deal with the fact that there are assembly implementations of various underlying primitives for each (optimised) platform supported, and is currently coded very much like a house of cards. All Richard wanted to achieve was some "constification" of the API so that even if internally the code is utter spaghetti, at least people using the API aren't being forced into dumb programming practices. However, trying to follow the constification through (rather than casting it away) has managed to knock a big chunk out of the performance numbers and also (apparently) created an error that fails a test somewhere. That alone is testimony to where our problems lie - and it is *not* in the fact we try to constify the API even if it means some necessary (for now) deconstifying in the code. psmith IMHO this is a legitimate reason to cast away const, and that psmith the "const" notation on the arguments to lhash is useful for psmith self-documentation purp
RE: Constification
-Original Message-
From: Richard Levitte - VMS Whacker [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, November 07, 2000 8:55 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: Constification
From: "Paul D. Smith" [EMAIL PROTECTED]
psmith This is similar to standard C functions which take a const
psmith char*, for example, and return a char* that points into the
psmith string.
Like strstr()...
psmith IMHO this is a legitimate reason to cast away const, and that
psmith the "const" notation on the arguments to lhash is useful for
psmith self-documentation purposes, at the least.
Hmm, perhaps you're right. I'm just a bit worried about how hard it
might become if someone is stupid enough to actually use the returned
(non-const) pointer to change something that is on RO memory...
There's no alternative in C. In C++ you may use overloading as in:
extern const char* f(const char* s);
inline char* f(char* s) { return (char*)f((const char*)s); }
assuming, of course, that f returns a pointer in the passed string.
Regards,
Bernard
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:+33 (0) 1 47 68 80 80
Fax:+33 (0) 1 47 88 97 85
e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: Constification
Richard Levitte - VMS Whacker wrote: From: "Paul D. Smith" [EMAIL PROTECTED] psmith This is similar to standard C functions which take a const psmith char*, for example, and return a char* that points into the psmith string. Like strstr()... Just because the C libraries are broken doesn't mean we should break ours. In Apache we fix these rather than live with them. psmith IMHO this is a legitimate reason to cast away const, and that psmith the "const" notation on the arguments to lhash is useful for psmith self-documentation purposes, at the least. Hmm, perhaps you're right. I'm just a bit worried about how hard it might become if someone is stupid enough to actually use the returned (non-const) pointer to change something that is on RO memory... Exactly. Cheers, Ben. -- http://www.apache-ssl.org/ben.html "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Constification
%% Ben Laurie [EMAIL PROTECTED] writes: Like strstr()... bl Just because the C libraries are broken doesn't mean we should bl break ours. In Apache we fix these rather than live with them. How exactly do you fix them? -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://www.paulandlesley.org/gmake/ "Please remain calm...I may be mad, but I am a professional." --Mad Scientist __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Constification
From: Ben Laurie [EMAIL PROTECTED]
ben Like strstr()...
ben
benbl Just because the C libraries are broken doesn't mean we should
benbl break ours. In Apache we fix these rather than live with them.
ben
ben How exactly do you fix them?
ben
ben By wrapping them with correctly declared functions.
So, either:
const char *correct_strstr(const char *s1, const char *s2)
{
return strstr(s1, s2);
}
or:
char *correct_strstr(char *s1, const char *s2)
{
return strstr(s1, s2);
}
Is that right? Both of those have problems. The first because you
can't manipulate the result even if the strings you gave from the
start are non-const, and the second because you can't give it a 'const
char *' as first argument...
--
Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED]
Chairman@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47
Redakteur@Stacken \ SWEDEN \ or +46-709-50 36 10
Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/
Software Engineer, Celo Communications: http://www.celocom.com/
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: Constification
%% Ben Laurie [EMAIL PROTECTED] writes: bl By wrapping them with correctly declared functions. Are you saying you just don't use const, or that you provide two different functions or two interfaces to the same function? I don't think either of these two options is better than deconstifying in this particular commonly-used way. The fact is that C's const is not robust enough to handle all these cases, so we have to handle them by convention rather than compiler-imposed fiat. This convention is well-used and well-understood, and I believe the benefits outweigh the problems. lhash is a basic library, and if we say you can't store const data in lhash (without casting const away first) that's going to have a lot of ripple effect. If I'm missing something maybe you could provide an actual example of what you mean, say using the crypto/lhash/lhash.c:lh_insert() function. The problems in BN are much more severe; in my unconst'ing efforts in May I went down _exactly_ the same path Richard is going down, and was forced to back up and remove all the const'ing I'd done in BN for exactly the reasons we are discussing. In this case I agree with Ben that const means the function _cannot_, under _any_ circumstances, modify the const data. Either the function has to be rewritten to avoid that need, or it can't be made const. However, the lhash case is, I think, much more straightforward. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://www.paulandlesley.org/gmake/ "Please remain calm...I may be mad, but I am a professional." --Mad Scientist __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Constification
On Wed, Nov 08, 2000 at 04:01:13PM +0100, Richard Levitte - VMS Whacker wrote:
So, either:
const char *correct_strstr(const char *s1, const char *s2)
{
return strstr(s1, s2);
}
or:
char *correct_strstr(char *s1, const char *s2)
{
return strstr(s1, s2);
}
Is that right? Both of those have problems. The first because you
can't manipulate the result even if the strings you gave from the
start are non-const, and the second because you can't give it a 'const
char *' as first argument...
HP-UX says:
char *strstr(const char *s1, const char *s2);
I read this: s1 and s2 are passed to strstr(). strstr() will not modify
the locations s1 and s2 are pointing to, so the optimizer may safely
assume that they have not been changed after the call to strstr().
That does not make any statement about what the calling function does
with s1 (and hence the return value _must_not_ be "const char *").
Sorry, couldn't resist :-)
Lutz
--
Lutz Jaenicke [EMAIL PROTECTED]
BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: Constification
Richard Levitte - VMS Whacker wrote: I've become irritated enough with some functions not having const used properly (or at least what appears proper), so I've started working on bringing better use of const to OpenSSL, as some may already have noticed. This may, for a few days, bring along a number of warnings or errors because everything that should be constified will not become constified at once, mostly for logging reasons. There's a couple of areas I noticed that could be constified. The EVP library's use of EVP_MD and EVP_CIPHER is the main one. I also noticed that the version strings for some reason weren't constified. 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: Constification
From: Dr S N Henson [EMAIL PROTECTED] drh There's a couple of areas I noticed that could be constified. The EVP drh library's use of EVP_MD and EVP_CIPHER is the main one. I also noticed drh that the version strings for some reason weren't constified. Thanks, I'll look at those next (after I've dealt with DSA and DH). -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Chairman@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 Redakteur@Stacken \ SWEDEN \ or +46-709-50 36 10 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Software Engineer, Celo Communications: http://www.celocom.com/ 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: Constification
From: "Paul D. Smith" [EMAIL PROTECTED] psmith This is similar to standard C functions which take a const psmith char*, for example, and return a char* that points into the psmith string. Like strstr()... psmith IMHO this is a legitimate reason to cast away const, and that psmith the "const" notation on the arguments to lhash is useful for psmith self-documentation purposes, at the least. Hmm, perhaps you're right. I'm just a bit worried about how hard it might become if someone is stupid enough to actually use the returned (non-const) pointer to change something that is on RO memory... -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Chairman@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 Redakteur@Stacken \ SWEDEN \ or +46-709-50 36 10 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Software Engineer, Celo Communications: http://www.celocom.com/ 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: Constification
%% Richard Levitte - VMS Whacker [EMAIL PROTECTED] writes: rl From: "Paul D. Smith" [EMAIL PROTECTED] psmith This is similar to standard C functions which take a const psmith char*, for example, and return a char* that points into the psmith string. rl Like strstr()... Yep. Plus strchr(), strrchr(), and strpbrk(), at least. psmith IMHO this is a legitimate reason to cast away const, and that psmith the "const" notation on the arguments to lhash is useful for psmith self-documentation purposes, at the least. rl Hmm, perhaps you're right. I'm just a bit worried about how hard it rl might become if someone is stupid enough to actually use the returned rl (non-const) pointer to change something that is on RO memory... Could be an issue, but remember that the function simply returns a point to memory it was passed. So the only way to get into this situation is to pass RO memory to the function in the first place, then "forget" and use the returned value as if it were RW. "const" isn't perfect by a long shot, but I prefer to leave these little loopholes lying around and do the best we can WRT getting the prototypes correct. "Knowing" that your data won't be modified by the function you're invoking because the argument is const is, IMO, a valuable thing. YMMV. (I realize that "knowing" requires that you trust the implementor, but we're all trustworthy here, right? :) -- --- Paul D. Smith [EMAIL PROTECTED]HASMAT--HA Software Methods Tools "Please remain calm...I may be mad, but I am a professional." --Mad Scientist --- These are my opinions---Nortel Networks takes no responsibility for them. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Constification
On Tue, Nov 07, 2000, Paul D. Smith wrote: I sent this patch back on 05 May 2000, constifying crypto/lhash. Your patch can only be accepted if you CC it to [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Constification
I've become irritated enough with some functions not having const used properly (or at least what appears proper), so I've started working on bringing better use of const to OpenSSL, as some may already have noticed. This may, for a few days, bring along a number of warnings or errors because everything that should be constified will not become constified at once, mostly for logging reasons. Also, this will bring about a few ugly casts in the ASN.1 macros or direct callers of them. This is a necessary step until the new ASN.1 code gets merged in and works properly... Please be patient. -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Chairman@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 Redakteur@Stacken \ SWEDEN \ or +46-709-50 36 10 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Software Engineer, Celo Communications: http://www.celocom.com/ 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: Constification
I've started working on bringing better use of const to OpenSSL
Huzzah.
Also, this will bring about a few ugly casts in the ASN.1 macros or
direct callers of them.
Perhaps something like
#define CONST(t, p) (const t)(p)
#define UNCONST(t, p) (t)(p)
As in
extern void bar(unsigned char** ucpp);
void foo(const unsigned char* ucp)
{
bar(UNCONST(unsigned char**,ucp));
}
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: Attempt at constification generates questions...
From: Ben Laurie [EMAIL PROTECTED] ben Woah! Let's not get carried away - unless they gain is actually zero, ben then constification is not justification, in itself, for doing this. ben Note, you could have a constified version that either didn't do ben BN_RECURSION or copied instead of expanding. That's what I ended up doing (actually, what was needed was a copying version of bn_expand2). I'm a little unsure about my solution, still, so I'll ponder it for a couple of days before I commit. -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Chairman@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 Redakteur@Stacken \ SWEDEN \ or +46-709-50 36 10 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Software Engineer, Celo Communications: http://www.celocom.com/ 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: Attempt at constification generates questions...
Richard Levitte - VMS Whacker wrote: I tried to constify the BIGNUM arguments to a few BN functions, among others BN_mul() (all but r). However, in BN_mul(), there's the BN_RECURSION case that will only occur when the lengths of a and b are 1 word from each other (if I understand correctly), and where a and b get expanded so the get the same length. I wonder, how much do we gain from BN_RECURSION? Could the whole thing be done in a way that doesn't need expanding a or b, so they can be const? Woah! Let's not get carried away - unless they gain is actually zero, then constification is not justification, in itself, for doing this. Note, you could have a constified version that either didn't do BN_RECURSION or copied instead of expanding. Cheers, Ben. -- http://www.apache-ssl.org/ben.html "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." Robert Woodruff __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Attempt at constification generates questions...
On Fri, Nov 03, 2000 at 09:16:56AM +, Ben Laurie wrote: Richard Levitte - VMS Whacker wrote: I tried to constify the BIGNUM arguments to a few BN functions, among others BN_mul() (all but r). However, in BN_mul(), there's the BN_RECURSION case that will only occur when the lengths of a and b are 1 word from each other (if I understand correctly), and where a and b get expanded so the get the same length. I wonder, how much do we gain from BN_RECURSION? Could the whole thing be done in a way that doesn't need expanding a or b, so they can be const? Woah! Let's not get carried away - unless they gain is actually zero, then constification is not justification, in itself, for doing this. Note, you could have a constified version that either didn't do BN_RECURSION or copied instead of expanding. I think copying wouldn't be the way to do it -- rather, merely check if the BIGNUM is already large enough and has the extra word set to 0. Just if this is not the case, copying may make sense. And usually, the numbers will be of the same size anyway (unless the size difference is so large that the recursive algorithm is not enabled anyway). -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
