Re: Sadistic C compiler...

[Bodo Moeller]

Andy Polyakov <[EMAIL PROTECTED]>:

>> The function pointer *must* be inside a data object to make such constructs
>> legal,

> But that's what Richard (subconsciously?) attempted to do in first
> place:
> 
> static void (*mem_cb)()=NULL;
> 
> void CRYPTO_mem_leaks_cb(void (*cb)())
> {
> ...
> mem_cb=cb;
> lh_doall_arg(mh,(void (*)())cb_leak,(char *)mem_cb);
> mem_cb=NULL;
> ...
> }

That's weird, I did not notice this and don't know why he did it this way
(and probably he doesn't either :-).

This is however not what I meant, this is just like calling

 lh_doall_arg(mh,(void (*)())cb_leak,(char *)cb);

without using the extra static variable.  We're still passing
a function pointer value.  What would work, however, is

> void CRYPTO_mem_leaks_cb(void (*cb)())
> {
> ...
> void *cb_ptr=&cb;
> lh_doall_arg(mh,(void (*)())cb_leak,cb);
> ...
> }

(there's no reason to introduce a struct unless one wants to do things
over-complicated, I don't know why I mentioned structs before).
The point is that C doesn't like mixing function pointers and data
object pointers; they don't necessarily have identical
representations (you could have 32 bit function pointers, but 64
bit data pointers).  To force C to convert values between these types,
you'd have to cast to some integer type inbetween:

(void (*)()) (long) cb

But of course this is so complicated because it should never be done
and is not guaranteed to do anything useful.  &cb, on the other hand,
is the pointer to some data object; the function that gets this
pointer as an argument has to retrieve the actual function pointer
from inside this data object, i.e. use *((void (**)()) arg)
where arg is the void * argument passed to it.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Sadistic C compiler...

[Jeffrey Altman]

And more text:

5.6.2  Function and Array Identifiers as Arguments
  Function and array identifiers can be specified as argu-
  ments to a function.  Function identifiers are specified without
  parentheses, and array identifiers are specified without
  brackets.  When so specified, the function or array identifier
  is evaluated as the address of that function or array.  Also, the
  function must be declared or defined, even if its return value
  is an integer. Example 5-1   shows how and when to declare
  functions passed as arguments, and how to pass them.

  Key to Example 5-1:

   1  Without being declared in a separate declaration, function
  x can be passed in an argument list because its defi-
  nition, located before the function caller, serves as its
  declaration.

   2  Parameters that represent functions can be declared ei-
  ther as functions or as pointers to functions.  Parameters
  that represent arrays can be declared either as arrays or
  as pointers to the element type of the array.  For example:
  fn(int  f1(),  int  f2(),  int  a1[])   /*  f1,  f2
declared  as  */

  {...}/*  functions;  a1
declared  */
   /*  as  array  of
int.  */

  fn(int  (*f1)(),  int  (*f2)(),  int  *a1)  /*  f1,  f2
declared  as  */
  {...}/*  pointers  to
functions;  */
   /*  a1  declared  as
pointer  */
   /*  to  int.
 */

  When such parameters are declared as functions or
  arrays, the compiler automatically converts the corre-
  sponding arguments to pointers.

   3  Because its function definition is located after the function
  caller, function y must be declared before passing it in an
  argument list.

   4  When passing functions as arguments, do not include
  parentheses.  Similarly, when specifying arrays, do not
  include subscripts.

  Example 5-1:  Declaring Functions Passed as Arguments

 1  int  x()   {  return  25;  }   /*  Function  definition  and */
int  z[10];/*  array  defined  before use   */

 2  fn(int  f1(),  int  (*f2)(),  int  a1[])) /*  Function definition  */
{
f1();  /*  Call  to  function  f1 */
  .
  .
  .
}

void  caller(void)
{
 3  int  y();  /*  Function  declaration */
  .
  .
  .
 4  fn(x,  y,  z);/*  Function  call: functions   */
  /*  x  and  y,  and  array  z   */
  /*  passed  as  addresses */
  .
  .
  .
}

int  y(void)  {  return  30;  }   /*  Function  definition  */

6.11.2  Pointer Conversions
  Although two types (for example,int and  long) can have
  the same representation, they are still different types.  This
  means that a pointer to   int cannot be assigned to a pointer
  to long without using a cast.  Nor can a pointer to a func-
  tion of one type be assigned to a pointer to a function of a
  different type without using a cast.  In addition, pointers to
  functions that have different parameter-type information,
  including the old-style absence of parameter-type informa-
  tion, are different types.  In these instances, if a cast is not
  used, the compiler issues an error.  Because there are align-
  ment restrictions on some target processors, access through
  an unaligned pointer can result in a much slower access time
  or a machine exception.

  A pointer to void can be converted to or from a pointer to
  any incomplete or object type.  If a pointer to any incomplete
  or object type is converted to a pointer to void and back, the
  result compares equal to the original pointer.

  An integral constant expression equal to 0, or such an expres-
  sion cast to thevoid * type, is called anull pointer constant.  If
  a null pointer constant is assigned to or compared for equality
  with a pointer, the constant is converted to a pointer of that
  type.  Such a pointer is called anull pointer, and is guaranteed
  to compare unequal to a pointer to any object or function.

  An array designator is automatically converted to a pointer to
  the array type, and the pointer points to the first element of
  the array.




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  

Re: Sadistic C compiler...

[Richard Levitte - VMS Whacker]

levitte> BTW, I just discovered the following (about crypto/x509v3/v3_int.c):
levitte> 
levitte> (X509V3_EXT_S2I)NULL,
levitte> ^
levitte> %CC-I-NONSTANDCAST, In the initializer for v3_crl_num.s2i, "((void ...)0)" of 
type "pointer to void", is being converted to "pointer to function (pointer to struct 
v3_ext_method, pointer to struct v3_ext_ctx, pointer to char) returning pointer to 
void".  
levitte> Such a cast is not permitted by the standard.
levitte> at line number 70 in file 
DISK$ALPUTILS:[LEVITTE.WRK.OPENSSL-0_9_5-DEV.CRYPTO.X509V3]V3_INT.C;1


The solution is, of course, to change NULL to 0...

-- 
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  for more info.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Sadistic C compiler...

[Jeffrey Altman]

Maybe the following text from the Compaq C programmer's manual on
types will be helpful:

2.7  Compatible and Composite Types

  Compatibility between types refers to the similarity of two
  types to each other.  Type compatibility is important during
  type conversions and operations.  All valid declarations in the
  same scope that refer to the same object or function must
  have compatible types.  Two types are compatible if they fit
  any of the following categories:

  *   Two types are compatible if they are the same.

  *   Two qualified types (see Section 3.7) are compatible if they
  are identically qualified and the two types, unqualified,
  are compatible.  The order of the qualifiers in the type
  declaration does not matter.

  *   The types  short,signed short , short int, and signed short
  int are the same and are compatible.

  *   The types  unsigned short  and unsigned short int  are the
  same and are compatible.

  *   The types  int,signed , and signed int are the same and
  are compatible.

  *   The types  unsigned and  unsigned int  are the same and
  are compatible.

  *   The types  long,signed long ,long int ,signed long int  are
  the same and are compatible.

  *   The types  unsigned long  and unsigned long int  are the
  same and are compatible.

  *   Two array types are compatible if they are of the same
  size and contain elements of compatible types.  If one ar-
  ray has an unknown size, it is compatible with all other
  array types having compatible element types.

  *   Two unions or structures are compatible if they are de-
  clared in different compilation units, share the same
  members in the same order, and whose members have
  the same widths (including bit fields).

  *   Two enumerations are compatible if all members have
  the same values.  All enumerated types are compatible
  with other enumerated types.  An enumerated type is also
  compatible with the  signed int  type.

  *   Two pointer types are compatible if they are identically
  qualified and point to objects of compatible types.

  *   A function type declared using the old-style declaration
  (such as int tree( )) is compatible with another function
  type if the return types are compatible.

  *   A function type declared using the new prototype-style
  declaration (such as  int tree (int x)) is compatible with
  another function type declared with a function prototype
  if:

  -   The return types are compatible.

  -   The parameters agree in number (including an ellipsis
  if one is used).

  -   The parameter types are compatible.  For each pa-
  rameter declared with a qualified type, its type for
  compatibility comparison is the unqualified version of
  the declared type.

  *   The function type of a prototype-style function declara-
  tion is compatible with the function type of an old-style
  function declaration if the return types are compati-
  ble, and if the old-style declaration is not a definition.
  (Different styles of function declarations are discussed in
  Chapter 5.)  Otherwise, the function type of a prototype-
  style function declaration is compatible with the function
  type of an old-style function definition if all of the follow-
  ing conditions are met:

  -   The return types of the two functions are compatible.

  -   The number of parameters agree.

  -   The prototype-style function declaration does not
  contain an ellipsis as a parameter.

  -   The promoted types of the old-style parameters are
  compatible with the prototype-style parameter types.

  In the following example, the functions  tree  and tree2
  are compatible.  tree and  tree1 are not compatible,
  and tree1  and tree2  are not compatible.

  int  tree  (int);
  int  tree1  (char);
  int  tree2  (x)
 char  x;/*  char  promotes  to  int  in  old-style
   function  parameters,  and  so  is
   compatible  with  tree  */
 {
 ...
 };

  The following types, which may appear to be compatible, are
  not:

  *   unsigned int and  int types are not compatible.

  *   char,signed char , and unsigned char  types are not com-
  patible.

  Composite Type

  A composite type  is constructed from two compatible types
  and is compatible with both of the two types.  Composite types
  satisfy the following conditions:

  *   If one type is an array of known size, the composite
  type is an array of that size.  Otherwise, if one type is a
  variable-length array, the composite type is that type.

  *   If only one type is a function type with a prototype, the
  composite type is a function type with the parameter type
  list.

  *   

Re: Sadistic C compiler...

[Richard Levitte - VMS Whacker]

appro> > The function pointer *must* be inside a data object to make
appro> > such constructs legal,

appro> But that's what Richard (subconsciously?) attempted to do in
appro> first place:

Don't look at me, that part of the code was there in mem.c since
eons...

appro> static void (*mem_cb)()=NULL;
appro> 
appro> void CRYPTO_mem_leaks_cb(void (*cb)())
appro> {
appro> ...
appro> mem_cb=cb;
appro> lh_doall_arg(mh,(void (*)())cb_leak,(char *)mem_cb);
appro> mem_cb=NULL;
appro> ...
appro> }
appro> 
appro> I mean someting has prevented him from just "lh_doall_arg(mh,(void
appro> (*)())cb_leak,(char *)cb)," hasn't it?

I Actually don't know why Eric needed to do that.  But just for
clarity, let me show you what DEC C says:

void (*mem_callback)()=(void (*)())cb;
...^
%CC-I-NONSTANDCAST, In the initializer for mem_callback, "cb" of type "pointer to 
char", is being converted to "pointer to function () returning void".  Such a cast is 
not permitted by the standard.
at line number 668 in file 
DISK$ALPUTILS:[LEVITTE.WRK.OPENSSL-0_9_5-DEV.CRYPTO]MEM_DBG.C;3

lh_doall_arg(mh,(void (*)())cb_leak,(char *)mem_cb);
^
%CC-I-NONSTANDCAST, In this statement, "mem_cb" of type "pointer to function () 
returning void", is being converted to "pointer to char".  Such a cast is not 
permitted by the standard.
at line number 677 in file 
DISK$ALPUTILS:[LEVITTE.WRK.OPENSSL-0_9_5-DEV.CRYPTO]MEM_DBG.C;3


As you can see, whatever you do with the current scheme, there will
always be a conversion between function pointers and non-function
pointers.

appro> > so this is not silly at all.  An alternative would be to use
appro> > unions of a function pointer
appro> Why structures/unions? "lh_doall_arg(mh,(void (*)())cb_leak,(void
appro> *)&mem_cb)" should do...

The easiest way to avoid the conversions noted above is to have a
union like this:

union foo {
void *simple;
int (*fn)();
};

and use it internally.  You put whatever char * you want to convert to
a functino pointer into simple and pull out the function pointer from
fn, and vice versa.

appro> Of course provided that it's appropriately derefenced in
appro> cb_leak!

As you can see above, that's exactly one of the problems.

appro> And I fail to understand why mem_cb has to be declared static?

Not to be seen outside of the file?

appro> It can be perfectly declared in CRYPTO_mem_leaks_cb scope which
appro> also makes it multi-thead safe, doesn't it?

You're absolutely right about, but that is beside the point in this
case.  This is a ANSI C problem, not a MT problem.

appro> typedef void (*cb_t) ();
appro> 
appro> static void cb_leak(MEM *m, void *cb)
appro> {
appro> void (*mem_callback)()=*((cb_t *)cb);

You convert from void * to void (*)() (i.e. between a "simple
type" and a function pointer).  DEC C will complain.

appro> mem_callback(m->order,m->file,m->line,m->num,m->addr);
appro> }
appro> 
appro> void CRYPTO_mem_leaks_cb(void (*cb)())
appro> {
appro> void (*mem_cb)() = cb;
appro> if (mh == NULL) return;
appro> CRYPTO_w_lock(CRYPTO_LOCK_MALLOC2);
appro> lh_doall_arg(mh,(void (*)())cb_leak,(void *)(&mem_cb));

You convert from void (*)() to void * (i.e. between a "simple
type" and a function pointer).  DEC C will complain.

appro> CRYPTO_w_unlock(CRYPTO_LOCK_MALLOC2);
appro> }

-- 
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  for more info.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Sadistic C compiler...

[Richard Levitte - VMS Whacker]

BTW, I just discovered the following (about crypto/x509v3/v3_int.c):

(X509V3_EXT_S2I)NULL,
^
%CC-I-NONSTANDCAST, In the initializer for v3_crl_num.s2i, "((void ...)0)" of type 
"pointer to void", is being converted to "pointer to function (pointer to struct 
v3_ext_method, pointer to struct v3_ext_ctx, pointer to char) returning pointer to 
void".  
Such a cast is not permitted by the standard.
at line number 70 in file 
DISK$ALPUTILS:[LEVITTE.WRK.OPENSSL-0_9_5-DEV.CRYPTO.X509V3]V3_INT.C;1


that hurt...

-- 
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  for more info.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Sadistic C compiler...

[Richard Levitte - VMS Whacker]

drh> Hmmm. Does VMS have an equivalent to shared libraries which can
drh> be loaded at runtime?

drh> If so how is that handled?

Looks like this:

int status = LIB$FIND_FILE_SYMBOL(lib_file, symbol_name,
  &symbol_address, dir_spec, flags);

The secret is that LIB$FIND_FILE_SYMBOL is declared as having unknown
parameters (...), so you can give it whatever you like in there.  The
routine is pretty good at checking that the arguments make sense.

drh> There's normally a function in there that has to return a value
drh> that can be cast into any function pointer.

Doesn't help much in this case, does it ?  :-)

-- 
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  for more info.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Sadistic C compiler...

[Richard Levitte - VMS Whacker]

ssampson> > DEC C for VMS is getting really mean.
ssampson> 
ssampson> There's a reason DEC went out of business :-)

True.  However, that's not it.  DEC software has had a tendency to
hold quite high quality, and it seems that Compaq will keep that.

Sorry, but you really shot the wrong dog here...

-- 
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  for more info.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Sadistic C compiler...

[Richard Levitte - VMS Whacker]

bmoeller> The function pointer *must* be inside a data object to make
bmoeller> such constructs legal, so this is not silly at all.

Perfectly right.  My "silly" wasn't completely serious...

Anyway, thanks for the input, it confirmed that my thoughts were
right.  Time to hack :-).

-- 
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  for more info.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Undefined reference

[Ulf Möller]

> libcrypto.a(rsa_eay.o)(.text+0x138):rsa_eay.c: undefined reference to
> `RSA_padding_add_PKCS1_OAEP'
>  
> I've searched through all sources, but it's not found anywhere.

It's in crypto/rsa/rsa_oaep.c

Maybe you're using a DOS filesystem which can't keep rsa_oaep.c and
rsa_oaep_test.c in the same directory. In that case, remove the test
file.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Undefined reference

[Gisle Vanem]

On Mon, 17 Jan 2000, Ulf Möller wrote:

:> libcrypto.a(rsa_eay.o)(.text+0x138):rsa_eay.c: undefined reference to
:> `RSA_padding_add_PKCS1_OAEP'
:>  
:> I've searched through all sources, but it's not found anywhere.
:
:It's in crypto/rsa/rsa_oaep.c
:
:Maybe you're using a DOS filesystem which can't keep rsa_oaep.c and
:rsa_oaep_test.c in the same directory. In that case, remove the test
:file.

This must be the single exception to the 8.3 naming rule you're so
careful about.

BTW. pkcs8.c is found in two places. In ./apps and ./crypto/asn1.
This causes trouble when my (and others?) makefiles put all objects
in same directory.

BTW2. After compiling 0.9.5-SNAPSHOT16012000, more undefined have crept
up; SHA_Init, SHA1_Init, SHA_Final, SHA1_Final etc. Is this also caused
by long file-names?

Gisle V.

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

Re: ./Configure for MacOS X Server?

[Wilfredo Sanchez]

  Add this line to Makefile.ssl and you're all set:

"Rhapsody","cc:-O3 -fomit-frame-pointer -Wall::(unknown)",

-Fred


--
   Wilfredo Sanchez, [EMAIL PROTECTED]
Apple Computer, Inc., Core Operating Systems / BSD
  Open Source Engineering Lead
   1 Infinite Loop, 302-4K, Cupertino, CA 95014

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

Re: Sadistic C compiler...

[Andy Polyakov]

And why not even get rid of mem_cb:-)
> 
> typedef void (*cb_t) ();
> 
> static void cb_leak(MEM *m, void *cb)
> {
> void (*mem_callback)()=*((cb_t *)cb);
> mem_callback(m->order,m->file,m->line,m->num,m->addr);
> }
> 
> void CRYPTO_mem_leaks_cb(void (*cb)())
> {
#if 0
> void (*mem_cb)() = cb;
#endif
> if (mh == NULL) return;
> CRYPTO_w_lock(CRYPTO_LOCK_MALLOC2);
#if 0
> lh_doall_arg(mh,(void (*)())cb_leak,(void *)(&mem_cb));
#else
  lh_doall_arg(mh,(void (*)())cb_leak,(void *)(&cb));
#endif
> CRYPTO_w_unlock(CRYPTO_LOCK_MALLOC2);
> }
> 
And as for multi-thread safety. CRYPTO_w_lock is supposed to take care
of it, right? I mean my comment wasn't really relevant, huh?

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

Re: Compile problem

[Andy Polyakov]

> > I was compiling openssl-0.9.4 on my RedHat 6.1 Linux system.  The
> > compile died near the library building step with "cc caught signal 11,
> > internal compiler error".
> 
> You should include the file and line number where the error occured.
> Anyway, compiler bugs should be reported to RedHat; we might be able
> to provide a workaround at best.
Well, unless it's one of cases listed in http://www.bitwizard.nl/sig11/.
Redhat 6.1 is equipped with egcs-1.1.2 which is known to be able to
compile openssl-0.9.4.

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

Re: Sadistic C compiler...

[Andy Polyakov]

> > DEC C for VMS is getting really mean. Version 6.2
  ^^^ It has nothing to do with VMS. It complains about
casts between (*) and * even on Unix.
> 
> > It's especially visible in all the places where lh_doall_arg() gets a
> > casted function pointer as last argument (for example, see
> > CRYPTO_mem_leaks_cb() in crypto/mem_dbg.c)...
> >
> > I can imagine using silly things like a struct around the function
> > pointer to get rid of that warning.
> 
> The function pointer *must* be inside a data object to make such constructs
> legal,
But that's what Richard (subconsciously?) attempted to do in first
place:

static void (*mem_cb)()=NULL;

void CRYPTO_mem_leaks_cb(void (*cb)())
{
...
mem_cb=cb;
lh_doall_arg(mh,(void (*)())cb_leak,(char *)mem_cb);
mem_cb=NULL;
...
}

I mean someting has prevented him from just "lh_doall_arg(mh,(void
(*)())cb_leak,(char *)cb)," hasn't it?
> so this is not silly at all.  An alternative would be to use
> unions of a function pointer
Why structures/unions? "lh_doall_arg(mh,(void (*)())cb_leak,(void
*)&mem_cb)" should do... Of course provided that it's appropriately
derefenced in cb_leak! And I fail to understand why mem_cb has to be
declared static? It can be perfectly declared in CRYPTO_mem_leaks_cb
scope which also makes it multi-thead safe, doesn't it? To summarize:

typedef void (*cb_t) ();

static void cb_leak(MEM *m, void *cb)
{
void (*mem_callback)()=*((cb_t *)cb);
mem_callback(m->order,m->file,m->line,m->num,m->addr);
}

void CRYPTO_mem_leaks_cb(void (*cb)())
{
void (*mem_cb)() = cb;
if (mh == NULL) return;
CRYPTO_w_lock(CRYPTO_LOCK_MALLOC2);
lh_doall_arg(mh,(void (*)())cb_leak,(void *)(&mem_cb));
CRYPTO_w_unlock(CRYPTO_LOCK_MALLOC2);
}

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

Re: Checking for memory leaks

[Bodo Moeller]

Remo Inverardi <[EMAIL PROTECTED]>:

>> Before the program exits, call EVP_cleanup() and ERR_free_strings()
>> to free the memory allocated in these steps.

> Mmh, how come I've never read about these functions before?

You haven't read apps/openssl.c :-)

> Is
> there any place where I can get an idea of what every function
> in the library is good for?

No (not yet, at least).  The documentation sub-tree is groing
in the current development version, but there's about nothing on the
SSL library.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: BSAFE patch to openssl

[Tom Vaughan]

"G.Madhusudan" <[EMAIL PROTECTED]> writes:

> This is a patch to openssl-0.9.3a that allows openssl to be
> built with BSAFE. It is essentially the adaptation of Gordon
> Chaffee's work - BSAFE patch for SSLeay0.9.0.
> See http://bmrc.berkeley.edu/people/chaffee/ssleay/ssleay.html
> 
> Save the patch attached with this mail.
> To apply the patch do -
>   patch -p0 < OpenSSL-0.93a_BSAFE_patch
> 
> The patch has been tested on Linux.
> Madhu

This would be very nice to have added to OpenSSL. Any chance of this what
with the new US crypto regs and all?

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

Undefined reference

[Gisle Vanem]

I'm trying to build OpenSSL 0.9.4 (Aug 1999) with djgpp under DOS.
Everything is going well except this error while linking hmactest.exe
and others:
 
libcrypto.a(rsa_eay.o)(.text+0x138):rsa_eay.c: undefined reference to
`RSA_padding_add_PKCS1_OAEP'
 
I've searched through all sources, but it's not found anywhere. Only
way out AFAICS is to add "NO_SHA" to CFLAGS, but that gives even
more troubles. What should I do?

Gisle V.



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

Re: Sadistic C compiler...

[Dr Stephen Henson]

Richard Levitte - VMS Whacker wrote:
> 
> DEC C for VMS is getting really mean.  Version 6.2 (latest, as far as
> I know) spews out a message when a (char *) cast is done to a function
> pointer and vice versa.  Guess what it finds a little here and there
> in OpenSSL?  :-)
> 
> Changing (char *) to (void *) (that has been know to do magic
> sometimes) doesn't help.
> 

Hmmm. Does VMS have an equivalent to shared libraries which can be
loaded at runtime? If so how is that handled? There's normally a
function in there that has to return a value that can be cast into any
function pointer.

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: Sadistic C compiler...

[Bodo Moeller]

On Mon, Jan 17, 2000 at 01:06:27AM +0100, Richard Levitte - VMS Whacker wrote:

> DEC C for VMS is getting really mean.  Version 6.2 (latest, as far as
> I know) spews out a message when a (char *) cast is done to a function
> pointer and vice versa.

Every compiler should print such warnings, such casts are by no means
guaranteed to work.

> It's especially visible in all the places where lh_doall_arg() gets a
> casted function pointer as last argument (for example, see
> CRYPTO_mem_leaks_cb() in crypto/mem_dbg.c)...
> 
> I can imagine using silly things like a struct around the function
> pointer to get rid of that warning.

The function pointer *must* be inside a data object to make such constructs
legal, so this is not silly at all.  An alternative would be to use
unions of a function pointer and a data pointer (casts between
different function pointer types are legal, you just have to make
sure that you call the function as the same type as it was originally
defined -- OpenSSL even fails at this) instead of just a void *,
but that's probably more complicated than depositing the function pointer
in a struct.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Sadistic C compiler...

[Steve Sampson]

> 
> DEC C for VMS is getting really mean.

There's a reason DEC went out of business :-)

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

Re: Sadistic C compiler...

[Ben Laurie]

Richard Levitte - VMS Whacker wrote:
> 
> DEC C for VMS is getting really mean.  Version 6.2 (latest, as far as
> I know) spews out a message when a (char *) cast is done to a function
> pointer and vice versa.  Guess what it finds a little here and there
> in OpenSSL?  :-)

Presumably this is because it is potentially possible for them to be
incompatible (e.g. on segmented architectures).

> Changing (char *) to (void *) (that has been know to do magic
> sometimes) doesn't help.
> 
> It's especially visible in all the places where lh_doall_arg() gets a
> casted function pointer as last argument (for example, see
> CRYPTO_mem_leaks_cb() in crypto/mem_dbg.c)...
> 
> I can imagine using silly things like a struct around the function
> pointer to get rid of that warning.  Other solutions?  Comments?

Time for more typesafety?

Cheers,

Ben.

--
SECURE HOSTING AT THE BUNKER! http://www.thebunker.net/hosting.htm

http://www.apache-ssl.org/ben.html

"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
 - Indira Gandhi
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Checking for memory leaks

[Remo Inverardi]

>Before the program exits, call EVP_cleanup() and ERR_free_strings()
>to free the memory allocated in these steps.

Mmh, how come I've never read about these functions before? Is
there any place where I can get an idea of what every function
in the library is good for? I'm sorry, but I didn't find any
reference to an API overview in the 0.9.4 build.

Thanks, Remo
___

[ [EMAIL PROTECTED] ] "Ich dusche warm!" [ http://public.toilet.ch/ ]
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

SGC obsolete? (Was Re: Exporting (SGC) keys from IIS -> OpenSSL)

[Mark J Cox]

> Having said that SGC might now become obsolete anyway.

I think it will take some time for this to happen; we've got to wait for
MS and Netscape to release full-strength versions, then wait for everyone
to upgrade to them.  Theres still a large percentage of people who hit our
site with browsers that can't do SGC

Mark




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

Re: VxWorks Porting

[Lennart Bång]

Hi,

I have done a port of OpenSSL to another RTOS, "OSE". Maybe I can help you,
what are your specific questions?

Regards,

Lennart Bang
[EMAIL PROTECTED]

Asaf Steinfeld wrote:

> Hi All,
>
> Does someone have an experience with porting the toolkit to VxWorks real time 
>operating system?
>
> I will appreciate any help on this subject.
>
> Thanks,
>
> Asi Steinfeld
> __
> OpenSSL Project http://www.openssl.org
> Development Mailing List   [EMAIL PROTECTED]
> Automated List Manager   [EMAIL PROTECTED]

begin:vcard 
n:Bang;Lennart
tel;cell:+46 70 733 14 70
tel;fax:+46 8 732 63 10
tel;work:+46 8 446 34 67
x-mozilla-html:TRUE
url:www.netstream.se
org:Netstream AB;Networking department
version:2.1
email;internet:[EMAIL PROTECTED]
title:http://www.netstream.se
adr;quoted-printable:;;Enhagsbacken 9=0D=0A;S-187 40 Taby;;;Sweden
fn:Lennart Bang
end:vcard