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]
[openssl.org #85] Re: [wvstreams-dev] list dead??
On Wed, Jun 05, 2002 at 10:05:08PM -0400, Dusty Phillips wrote: Is there no action on this list? Well, no, there isn't. One reason is that Patrick hasn't had time to get nightly snapshots working, so I'm embarrassed to talk about changes immediately when we do them (eg. the recent really cool WvString - WvFastString/WvStringParm changes that get rid of the need for stupid WvString::unique(), and the new experimental hierarchical WvConf stuff). I'm still having trouble compiling wvstreams... That's not good. -- Making all in /usr/src/programsrc/wvstreams-3.70/src/crypto... make[2]: *** Warning: File `Makefile' has modification time in the future (2002-06-05 15:04:15 2002-06-05 10:08:53) Building on NFS or something? You should check your clock. g++ $_R_CXXFLAGS -c wvcrypto.cc wvcrypto.cc: In method `WvRSAKey::WvRSAKey(const char *, bool)': wvcrypto.cc:162: passing `unsigned char **' as argument 2 of `d2i_RSAPrivateKey(RSA **, const unsigned char **, long int)' adds cv-quals without intervening `const' wvcrypto.cc:173: passing `unsigned char **' as argument 2 of `d2i_RSAPublicKey(RSA **, const unsigned char **, long int)' adds cv-quals without intervening `const' I looked this up in google, and I found this message: http://www.geocrawler.com/archives/3/362/1997/9/0/2036587/ ...which explains where the error comes from. 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. As it is, there's no way I can write code that compiles with both the old and new openssl, so we'll have to stick with the non-beta openssl for now. My gcc is version 2.95.3, and openssl was 0.97beta or whatever the latest release is (jun 2). I'm installing this on a fairly new linux from scratch system. What do these errors mean? what am I doing wrong? I'm using gcc 2.95.3 and openssl 0.9.6c, and it works. I'll cc: this message to the openssl guys while I'm here. Thanks! Avery __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
