Richard Levitte - VMS Whacker wrote:
In message [EMAIL PROTECTED] on Wed, 8 Nov 2006 21:59:19 -0800, David
Schwartz [EMAIL PROTECTED] said:
davids You are correct, but that's not the issue. The issue is this
davids simple -- if you are going to call a function whose types you
davids don't
David Schwartz wrote:
x is still just a pointer to data - so it's the same
length in any case, all pointers to lvalues are the
same length in C. The only issue there is whether it's
aligned correctly - that's the programmers problem.
Length is not the issue. There is no rule that says that
Length is not the issue. There is no rule that says that two types must be
passed the same way just because they're the same length. For example, some
platforms may pass a 64-bit floating point number in a floating point
register but pass a 64-bit integer in an integer register.
I'm not sure
Using openssl 0.9.7 (can't upgrade - can't test newer versions)
openssl dgst won't list its options easily, except like this:
openssl dgst -help
unknown option '-help'
options are
-c to output the digest with separating colons
-d to output debug info
-hex
This mail is addressed to Dr Stephen N. Henson in connection with his previous
post.
I have never come across a report of a deadlock in that situation and several
applications have reported using WSAEventSelect() in the past. There are
several possible reasons...
There is very,very little
Howdy,
In the PKCS7_encrypt function, the intent is to make an envelop
and ecrypt the data pointed to by the parameter 'in'. But
PKCS7_dataInit(), where the encryption is supposed to take place, does
not operate on the parameter 'in'. And PKCS7_dataFinal is not taking
care of any
This mail is addressed to Davis Schwartz.
Well, I have asked my question on this developer mailing list and I have got
answer from one of the openSSL main developers. In this answer he suggested me
possible solutions, confirmed (by giving answer) that my problem is real. He
did it in his FIRST
davids simple -- if you are going to call a function whose types you
davids don't know (through a prototype), you must cast each type you
davids pass to the type the function expects. End of story. OpenSSL
davids does not do this. This is not valid C whether or not the type
davids sizes are
On Thu, Nov 09, 2006, Ricky Charlet wrote:
Howdy,
In the PKCS7_encrypt function, the intent is to make an envelop
and ecrypt the data pointed to by the parameter 'in'. But
PKCS7_dataInit(), where the encryption is supposed to take place, does
not operate on the parameter 'in'. And
On Thu, Nov 09, 2006, Richard Salz wrote:
davids simple -- if you are going to call a function whose types you
davids don't know (through a prototype), you must cast each type you
davids pass to the type the function expects. End of story. OpenSSL
davids does not do this. This is not
On Thursday 09 November 2006 02:04, Alaka Pathy wrote:
Hi All,
I recently built OpenSSL 0.9.7l binaries in a Solaris
machine.
As in, you compiled source you downloaded?
When I check the version, I get as 0.9.8d, whereas for
Windows I do get the version correctly as 0.9.7l.
Is there a
Thus spake Peter Waltenberg
x is still just a pointer to data - so it's the same length in any
case, all
pointers to lvalues are the same length in C. The only issue there is
whether it's aligned correctly - that's the programmers problem.
It's not the only problem.
Mixing something like
Incorrect. When the compiler encounters this statement, if there's no
prototype for d2i() in scope, it is _required_ to act as if the
prototype were:
int d2i(int, int, int);
This is wrong. The usual integral promotions apply -- but only to
integral parameters, not to ALL of them.
Stephen Sprunk wrote:
Thus spake Peter Waltenberg
x is still just a pointer to data - so it's the same length in any
case, all
pointers to lvalues are the same length in C. The only issue there is
whether it's aligned correctly - that's the programmers problem.
It's not the only problem.
davids simple -- if you are going to call a function whose types you
davids don't know (through a prototype), you must cast each type you
davids pass to the type the function expects. End of story. OpenSSL
davids does not do this. This is not valid C whether or not the type
davids sizes
On Thu, Nov 09, 2006, Dr. Stephen Henson wrote:
On Thu, Nov 09, 2006, Richard Salz wrote:
davids simple -- if you are going to call a function whose types you
davids don't know (through a prototype), you must cast each type you
davids pass to the type the function expects. End of
As I understood it, calling a function without a prototype was precisely
equivalent to declaring a prototype of the function with the exact
parameter
types passed (after promotion rules).
Nope. Calling a function without a prototype is precisely equivalent to
KR rules. If a function will
Once KR is included, the situation becomes a lot less clear. Also, as I
read the thread on the GCC list, it looks like the situation is further
complicated by their desire to avoid an internal compiler error.
Also**2,
I don't know what you mean by C's aliasing rules; to me that brings to
On 11/9/06, David Schwartz [EMAIL PROTECTED] wrote:
Once KR is included, the situation becomes a lot less clear. Also, as I
read the thread on the GCC list, it looks like the situation is further
complicated by their desire to avoid an internal compiler error.
Also**2,
I don't know what
19 matches
Mail list logo
