X509_vfy.h and C++

[Gisle Vanem]

This file has a 'explicit' struct x509_store_ctx_st member. This words is 
unfortunetely a C++ reserved word in g++ 3.4.1 at least. And from a bit of 
googling, has been a reserved word for more than 6 years.

I suggest we replace with 'explicit_policy'.
--- crypto/x509v3/x509_vfy.h.orig Sat Sep 18 04:00:11 2004
+++ crypto/x509v3/x509_vfy.h  Fri Oct 01 10:03:47 2004
@@ -254,7 +254,7 @@
   STACK_OF(X509) *chain;  /* chain of X509s - built up and trusted */
   X509_POLICY_TREE *tree; /* Valid policy tree */
-   int explicit;   /* Require explicit policy value */
+   int explicit_policy;/* Require explicit policy value */
   /* When something goes wrong, this is why */
   int error_depth;
--- crypto/x509v3/x509_vfy.c.orig Mon Sep 06 21:00:14 2004
+++ crypto/x509v3/x509_vfy.c  Fri Oct 01 10:05:09 2004
@@ -747,7 +747,7 @@
static int check_policy(X509_STORE_CTX *ctx)
   {
   int ret;
-   ret = X509_policy_check(ctx-tree, ctx-explicit, ctx-chain,
+   ret = X509_policy_check(ctx-tree, ctx-explicit_policy, ctx-chain,
   ctx-param-policies, ctx-param-flags);
   if (ret == 0)
   {
@@ -1246,7 +1246,7 @@
   ctx-valid=0;
   ctx-chain=NULL;
   ctx-error=0;
-   ctx-explicit=0;
+   ctx-explicit_policy=0;
   ctx-error_depth=0;
   ctx-current_cert=NULL;
   ctx-current_issuer=NULL;
@@ -1398,7 +1398,7 @@
int X509_STORE_CTX_get_explicit_policy(X509_STORE_CTX *ctx)
   {
-   return ctx-explicit;
+   return ctx-explicit_policy;
   }
int X509_STORE_CTX_set_default(X509_STORE_CTX *ctx, const char *name)
--gv
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: X509_vfy.h and C++

[Dr. Stephen Henson]

On Fri, Oct 01, 2004, Gisle Vanem wrote:

 This file has a 'explicit' struct x509_store_ctx_st member. This words is 
 unfortunetely a C++ reserved word in g++ 3.4.1 at least. And from a bit of 
 googling, has been a reserved word for more than 6 years.
 
 I suggest we replace with 'explicit_policy'.
 

Oops, that one slipped through. I've committed a fix.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Funding needed! Details on homepage.
Homepage: http://www.drh-consultancy.demon.co.uk
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: compiling openssl-SNAP-20040910.tar.gz on OS X

[Raf Schietekat]

Richard Levitte - VMS Whacker wrote:
In message [EMAIL PROTECTED] on Mon, 27 Sep 2004 15:17:47 +0200, Raf Schietekat [EMAIL 
PROTECTED] said:
f0586712 Joseph Bruni wrote:
f0586712 
f0586712  When attempting to compile openssl-SNAP-20040910.tar.gz on Mac OS X 
f0586712  (10.3.5), I ran into a header file problem in 
f0586712  crypto/engine/eng_padlock.c. The malloc.h header is located in 
f0586712  /usr/include/malloc/malloc.h. See diff:
f0586712  
f0586712  --- crypto/engine/eng_padlock.c.origFri Sep 10 15:06:33 2004
f0586712  +++ crypto/engine/eng_padlock.c Fri Sep 10 15:03:59 2004
f0586712  @@ -65,7 +65,7 @@
f0586712  
f0586712   #include stdio.h
f0586712   #include string.h
f0586712  -#include malloc.h
f0586712  +#include malloc/malloc.h
f0586712   #ifdef _MSC_VER
f0586712   # define alloca   _alloca
f0586712   # define snprintf _snprintf
f0586712  
f0586712  After fixing this, the compile (including make test) worked fine.
f0586712 
f0586712 It seems to me that the appropriate way to declare malloc()
f0586712 is to #include stdlib.h rather than malloc.h (with an
f0586712 additional #include malloc.h inside the #ifdef
f0586712 _MSC_VER). Don't take my word for it, just consult the
f0586712 standard documents for C(++), several manual pages
f0586712 (including the one for Darwin, underlying Mac OS X), and
f0586712 MSDN for MS-specific code. I'm sure malloc/malloc.h will
f0586712 be (ultimately) included from there, so there's no need to
f0586712 go ad hoc yourself. In openssl-SNAP-20040908, only this file
f0586712 needs to be fixed, the rest (e_os.h, ms/uplink.c) is already
f0586712 using malloc.h only for MS-specific code.

True, if malloc() was the issue.  The thing is that eng_padlock.c uses
alloca(), which isn't standard.  On GNU systems, the correct header to
use is really alloca.h, BTW, at least according to the man page I'm
reading.
Do you have a solution for this that works better?
Sorry for the delay. alloca() indeed isn't standard (and several man pages 
discourage its use), but it's still #include stdlib.h on FreeBSD and Darwin. 
On Darwin (yes, either header can be used) and Red Hat, it's #include 
alloca.h. MSDN on the other hand states only malloc.h as a required header 
for _alloca(), without the stdlib.h it requires for malloc(). There's 
apparently no consensus here, so eng_padlock.c.diff may still need to be 
modified or checked for FreeBSD and Red Hat. (My sources are the nice 
multi-platform man page viewer on www.freebsd.org, and an admittedly rather old 
MSDN Library (from 2001-01).)

Raf Schietekat [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]