Ben Laurie wrote:
> > http://biz.yahoo.com/prnews/000118/ca_sun_net_1.html
> > <>
>
> Hmm. Doesn't say what language its in!
I think you're safe, Ben -- it's gotta be English. They stopped using
Euskera after I left Sun.
Cheers,
Michael
--
QUI ME AMET, CANEM MEUM ETIAM AMET
__
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:
>
> As always with Sun, the details are in the license. :) Since they're
> releasing it to Mozilla.org, however, then it's unlikely they'll use their
> problematic "community license."
>
>
> http://biz.yahoo.com/prnews/000118/ca_sun_net_1.html
> <>
Hmm. Doesn't say what l
"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
I was wondering if anybody ever managed to write functions which
emulate the standard socket read and write behaviour. My web server
uses the following logic to read from a socket:
a) do a select and wait until data is available
b) do a read (recv)
c) if read returns > 0 goto c1
if read ret
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
As always with Sun, the details are in the license. :) Since they're
releasing it to Mozilla.org, however, then it's unlikely they'll use their
problematic "community license."
http://biz.yahoo.com/prnews/000118/ca_sun_net_1.html
<>
Yahoo - The Sun-Netscape Alliance Releases PKI Library
> > > 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
Hi,
I'm trying to add SSL support to an existing Sockets class. The class uses
CAsyncSocket, and works under some conditions. I think it is a
blocking/non-blocking IO problem. Anyway, when I run the program normally, I
get errors in SSL_connect and SSL_accept. ERR_print_errors_fp gives no
further
> 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
> This must be the single exception to the 8.3 naming rule you're so
> careful about.
I have renamed it. The name rsa_test.c would have been better anyway
because we added tests for other modes than oaep quite some time ago.
> BTW. pkcs8.c is found in two places. In ./apps and ./crypto/asn1.
> T
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
Hi,
Firstly I apologise for the length of the mail note and also some of the
questions asked. But I have spent time reading various articles/books
and unfortunately I've become totally confused. So please be gentle
with any replies you send ;-)
I thought I had a reasonable grasp of:
a) how
29 matches
Mail list logo
