Re: VxWorks Porting
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
SGC obsolete? (Was Re: Exporting (SGC) keys from IIS - OpenSSL)
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: Checking for memory leaks
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]
Re: Sadistic C compiler...
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...
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...
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]
Undefined reference
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: BSAFE patch to openssl
"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]
Re: Sadistic C compiler...
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: Compile problem
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: ./Configure for MacOS X Server?
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: Undefined reference
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: Undefined reference
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: Sadistic C compiler...
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 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: Sadistic C compiler...
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 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: Sadistic C compiler...
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 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: Sadistic C compiler...
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 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: Sadistic C compiler...
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 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: Sadistic C compiler...
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...
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]
