On Thu, Jan 20, 2000, Richard Levitte - VMS Whacker wrote:
babinebell I think we should seperate the functions handling values
babinebell and the functions handling callbacks:
babinebell
babinebell int BIO_ctrl_callback(BIO *bp,int cmd,long larg,int (*cb)());
Hmm, actually, I like that
On Wed, Jan 26, 2000, Bodo Moeller wrote:
On Thu, Jan 20, 2000, Richard Levitte - VMS Whacker wrote:
Hmm, actually, I like that alternative. That allows us to go around
the whole union/pass-by-value/and-so-on brouhaha... :-)
Looks ok. Will you implement it?
Here "you" == Richard, in
bodo babinebell I think we should seperate the functions handling values
bodo babinebell and the functions handling callbacks:
bodo babinebell
bodo babinebell int BIO_ctrl_callback(BIO *bp,int cmd,long larg,int (*cb)());
bodo
bodo Hmm, actually, I like that alternative. That allows us to
It's *not* VMS specific! DEC C 6.2 for Unix issues very similar warning.
But it looks like DEC has VMS specific reason to be nervous about the
matter. Consider the following code:
#pragma required_pointer_size save /* Save the previous pointer size */
#pragma required_pointer_size 64 /* Set
babinebell I think we should seperate the functions handling values
babinebell and the functions handling callbacks:
babinebell
babinebell int BIO_ctrl_callback(BIO *bp,int cmd,long larg,int (*cb)());
babinebell
babinebell Is not nice, requires changing of some structures but
babinebell seems
Richard Levitte - VMS Whacker [EMAIL PROTECTED]:
Let me see if I got it all. So far, I've seen the following
alternatives:
1. ignore the problem (obviously not the right thing to do :-)).
2. take the parameter in question as we do today, but use a union so
the compiler will shut
Richard Levitte - VMS Whacker wrote:
4. Have the caller tuck the parameter in a union that will represent
function pointers as well as other pointers, and pass that union
by value.
5. Have the caller tuck the parameter in a union that will represent
function pointers as
Andy Polyakov [EMAIL PROTECTED]:
5. Have the caller tuck the parameter in a union that will represent
function pointers as well as other pointers, and pass that union
by reference.
Choices 4 and 5 assumes that the parameter in question will be
prototyped and used like this:
appro Why pass a reference? C has been able to passreturn aggregate types since
appro v7 :)
appro Because *that* would *definitely* have impact on *a lot* of things. Pass
appro by value is an option only if you reimplement all function dealing with
appro whitened parameter to callback
appro My vote is #5 for crypto/mem_dbg.c, crypto/bio/bss_conn.c,
appro ssl/s3_lib.c with new calls and separate ctl codes for binary
appro compatibility (I can fix up bss_conn.c and s3_lib.c to *show*
appro what I mean). I'll be back about o_names.c...
Below is what I ment for bss_conn.c.
appro Well, it's actually 3 and 5 which are the same. I.e. in the
Ah, right, I made the comparison from a language semantics point of
view...
appro It's a good way to deal with the problem in what could be perceived as
appro a safe way, but for a detail: there's no way to see from the API
appro *** ./bio.h.origMon Sep 27 16:00:09 1999
appro --- ./bio.h Thu Jan 20 16:57:00 2000
appro ***
appro *** 116,121
appro --- 116,122
appro /* callback is int cb(BIO *bio,state,ret); */
appro #define BIO_CTRL_SET_CALLBACK 14 /* opt - set callback function
Hmm. That's basically an anonymous choice 4 and 5 (depending on ctl
code).
Yes, that was my vote/proposal. Anonymous/whitened pointer argument is
the key to binary compatibility (at _ctrl level) and having anything
(anything at all) passed by value is not the right thing to do.
My thought
appro My thought about that one was that BIO_ctrl would be declared
appro and defined to take a 'sin_of_ansification *'
appro ^ you vote for #4, no star here.
Oops :-).
appro as argument instead of a
appro 'void *' (a non-anonymous variant 4).
And what if sizeof (void (*)()) != sizeof (void *)? Think MS-DOS and all
those sick small/medium/large/huge memory models if you have to. I
realize it's a sick thought, but that's what the compiler complains
about and that's why "such a cast is not permitted by the standard."
In this
appro Why not simply relax the compiler with /STANDARD=RELAXED or whatever:-)
Sure, we can do that. Is that the right thing to do?
":-)" was actually ment to designate the wrong thing.
We need to decide if this is something that actually warrants our
attention, or if we think it can be
appro Why pass a reference? C has been able to passreturn aggregate types since
appro v7 :)
appro Because *that* would *definitely* have impact on *a lot* of things. Pass
appro by value is an option only if you reimplement all function dealing with
appro whitened parameter to callback
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...
Sorry:-) I should have written
bmoeller cb,
bmoeller on the other hand, is the pointer to some data object; the
bmoeller function that gets this pointer as an argument has to
bmoeller retrieve the actual function pointer from inside this data
bmoeller object, i.e. use *((void (**)()) arg) where arg is the void
bmoeller *
bmoeller bit data pointers). To force C to convert values between
bmoeller these types, you'd have to cast to some integer type inbetween:
bmoeller
bmoeller (void (*)()) (long) cb
This may very well be a problem on architectures where a pointer is 64
bits while a long is 32 bits. I
Richard Levitte - VMS Whacker wrote:
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
appro Just to make it clear. Are you going to pass the union by
appro reference of by value? You have to pass by reference which is
appro equivalent to what I proposed, but without unions. Passing by
appro value would be wrong and compiler should complain.
As you have probably seen by now, I
Ben Laurie wrote:
Richard Levitte - VMS Whacker wrote:
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 *
appro Just to make it clear. Are you going to pass the union by
appro reference of by value? You have to pass by reference which is
appro equivalent to what I proposed, but without unions. Passing by
appro value would be wrong and compiler should complain.
As you have probably seen by now,
And what if sizeof (void (*)()) != sizeof (void *)? Think MS-DOS and all
those sick small/medium/large/huge memory models if you have to. I
realize it's a sick thought, but that's what the compiler complains
about and that's why "such a cast is not permitted by the standard."
In this
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
Why pass a reference? C has been able to passreturn aggregate types since
v7 :)
only way to do this validly is to make the functions
actually take a foo* as their argument, surely?
Yes you must do that.
I'll bet in most cases you can make the foo static
Unless I misunderstand what you mean,
Jeffrey Altman wrote:
.
4 fn(x, y, z);/* Function call: functions */
/* x and y, and array z */
/* passed as addresses */
A function pointer may not be an "address" -- in
appro Why not simply relax the compiler with /STANDARD=RELAXED or whatever:-)
Sure, we can do that. Is that the right thing to do? I remember that
at some point, it was "all hail ANSI C", something I support. But not
only that, if this problem is enough to actually create errors on
"MS-DOS
On Tue, Jan 18, 2000 at 10:59:53AM +0100, Richard Levitte - VMS Whacker wrote:
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
This may very well be a problem on architectures where a
Looks like a compiler bug; NULL is supposed to be safely castable to any
pointer type, and compared against any pointer type.
NULL is often a pound define and not a compiler name. Its definition
is very frequently
(char *)0
which is not comparable.
Jeffrey Altman * Sr.Software
SalzR Looks like a compiler bug; NULL is supposed to be safely
SalzR castable to any pointer type, and compared against any pointer
SalzR type.
Depends on. If NULL is defined like this:
#define NULL 0
then you're perfectly right, but if it's defined like this:
#define NULL
"Salz, Rich" wrote:
Why pass a reference? C has been able to passreturn aggregate types since
v7 :)
Good point.
only way to do this validly is to make the functions
actually take a foo* as their argument, surely?
Yes you must do that.
I'll bet in most cases you can make the foo
In the ANSI standard C sense, there is no real difference between the C
language and the supporting libraries.
I don't have a copy of the standard handy, but I'm fairly sure it can be
safely castable as I said before.
Therefore if Compaq's C compiler #define's it as void*,
then their "compiler"
Richard Levitte - VMS Whacker [EMAIL PROTECTED]:
[...]
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
SalzR In the ANSI standard C sense, there is no real difference
SalzR between the C language and the supporting libraries.
It's useless to discuss it unless someone can cite the exact words of
the standard here. Until then, we're just talking out of our behinds.
--
Richard Levitte \
Richard Levitte - VMS Whacker wrote:
SalzR In the ANSI standard C sense, there is no real difference
SalzR between the C language and the supporting libraries.
It's useless to discuss it unless someone can cite the exact words of
the standard here. Until then, we're just talking out of
Bodo Moeller wrote:
The clean way (and not just another "clever hack") would be
void SSL_CTX_set_tmp_rsa_callback(SSL_CTX *ctx,RSA *(*cb)(SSL *ssl,
int is_export,
int
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]
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
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
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
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
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...
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
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;
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,
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
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)())
{
...
49 matches
Mail list logo
