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
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, i
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
> 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 poi
On Mon, Jan 17, 2000 at 01:39:55PM +, Dr Stephen Henson wrote:
> 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
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> s
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 lik
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 a
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 wi
Hi there,
On Thu, 20 Jan 2000, Richard Levitte - VMS Whacker wrote:
> appro> > as argument instead of a
> appro> > 'void *' (a non-anonymous variant 4).
> appro> But it breaks *source* code compatibility and old users gonna
> appro> get (really) frustrated.
>
> That is true, but on the other ha
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 varian
At 17:31 20.01.00 +0100, Richard Levitte - VMS Whacker wrote:
Hallo Richard,
I fear we don't solve the problem but try to tweak a broken implementation
until it works.
I think we should seperate the functions handling values and the
functions handling callbacks:
int BIO_ctrl_callback(BIO *bp,in
> 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 a
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 fun
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> 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
> appro> > Why pass a reference? C has been able to pass&return 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
appro> > Why pass a reference? C has been able to pass&return 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 f
> 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 ca
> > 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."
>
>
> Why pass a reference? C has been able to pass&return aggregate types since
> v7 :)
Because *that* would *definitely* have impact on *a lot* of things. Pass
by value is an option only if you reimplement all function dealing with
whitened parameter to callback functions. I mean if you want to sti
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,
> in
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 o
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 \ Spannv
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 wan
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"
"Salz, Rich" wrote:
>
> Why pass a reference? C has been able to pass&return 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
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
> 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 Des
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 whe
Looks like a compiler bug; NULL is supposed to be safely castable to any
pointer type, and compared against any pointer type.
__
OpenSSL Project http://www.openssl.org
Development Mailing List
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 an
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 particul
Why pass a reference? C has been able to pass&return 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 mea
> > > 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
> 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 part
> 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 see
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 p
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
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
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
> 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
>
> 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
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)())
> {
>
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 o
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 functi
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
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)()=NU
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
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$
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.
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 Le
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)())
>
> > 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, se
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 *)
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, suc
>
> 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]
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 bec
58 matches
Mail list logo
