On Fri, Nov 10, 2006, Dr. Stephen Henson wrote:
OK, looks like inline calls is the way to go. Those at least have some
advantages over the existing stuff.
For gcc (4.0, 4.2 at least on X86) it looks like it will translate equivalent
(at a machine level) function calls into a single jump
The equivalent of the offending line would be
foo((double *)(void *) j);
since any access through a void pointer CAN change the value.
'(double *)(void *)' does not keep some sort of remnant of the 'void *'. The
final cast renders the end-result a 'double *' and negates the 'void *'. You
An object may be the type of its last cast -- but it also can't
exactly lose the benefit/cost of being cast to a pointer to an
undefined type. As soon as you undefine the type of a pointer, it
loses the remnant of ever having had the initial type in the first
place.
In KR C, you couldn't cast
I found the rule -- at least for C99. It is ISO 9899:1999 section
6.2.5, rule 26 and footnote 39:
26) A pointer to void shall have the same representation and alignment
requirements as a
pointer to a character type. Similarly, pointers to qualified or unqualified
versions of
An object may be the type of its last cast -- but it also can't
exactly lose the benefit/cost of being cast to a pointer to an
undefined type. As soon as you undefine the type of a pointer, it
loses the remnant of ever having had the initial type in the first
place.
Right, but that doesn't
This means you cannot pass an 'X509 **' as a 'char **'.
Unfortunately 'X509 *' and 'char *' are not compatible types because
'X509' and 'char' are not compatible. They are not both unions, they
are not both structures.
But you can pass 'X509 **' as 'void *'. So...
void
But you can pass 'X509 **' as 'void *'. So...
void x509func(void* p) { X509** pp = (X509**)p; ... }
void trampoline(void* p) { x509func(p); }
void caller(void) { X509* p; trampoline(p); }
should (MUST?) work just fine.
/r$
When I change my test programs
David Schwartz wrote:
An object may be the type of its last cast -- but it also can't
exactly lose the benefit/cost of being cast to a pointer to an
undefined type. As soon as you undefine the type of a pointer, it
loses the remnant of ever having had the initial type in the first
place.
Are you sure that problem is in cast ?
$ cat test.c
main() {
int j=2;
double *d=(double*)j;
*d=1.0;
printf(%d %e\n, j, *d);
printf(%d %e\n, j, *d);
}
gcc -O2 test.c ./a.out
2 1.00e+00
0 1.00e+00
Same result in case with line double *d=j; (but expected warning:
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
cc
@openssl.org
Subject
RE: OpenSSL breaks with gcc 4.2
09/11/06 03:59 PM
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, 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
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
David Schwartz wrote:
On Tue, Nov 07, 2006, Bernhard Rosenkraenzer wrote:
gcc 4.2 no longer allows function casting - which is used
rather heavily by
openssl. (To make things worse, it compiles but inserts abort()
statements
resulting in app crashes).
Ugh, I would've thought that
On Wed, Nov 08, 2006, Ben Laurie wrote:
But it gets cast back to the correct type before it is called. These
casts are done the way they are to get type-safety. Removing that option
strikes me as a bad thing.
Yes and that happened to be a way that worked on all the compilers OpenSSL
used
On Tuesday, 7. November 2006 15:54, Dr. Stephen Henson wrote:
On Tue, Nov 07, 2006, Bernhard Rosenkraenzer wrote:
gcc 4.2 no longer allows function casting - which is used rather heavily
by openssl. (To make things worse, it compiles but inserts abort()
statements resulting in app crashes).
But it gets cast back to the correct type before it is called. These
casts are done the way they are to get type-safety. Removing that option
strikes me as a bad thing.
It does not. Look closely at how these functions work:
char *PEM_ASN1_read_bio(char *(*d2i)(), const char *name, BIO *bp,
breaks with gcc
4.2
But it gets cast back to the correct type before it is called. These
casts are done the way they are to get type-safety. Removing that
option
strikes me as a bad thing.
It does not. Look closely at how these functions work:
char *PEM_ASN1_read_bio(char *(*d2i)(), const
Dr. Stephen Henson wrote:
On Wed, Nov 08, 2006, Ben Laurie wrote:
But it gets cast back to the correct type before it is called. These
casts are done the way they are to get type-safety. Removing that option
strikes me as a bad thing.
Yes and that happened to be a way that worked on all
On Thu, Nov 09, 2006, Peter Waltenberg wrote:
Please tell me how the compiler knows what type 'x'
should be passed as. If
you pass a pointer to a function as 'd2i' whose first type is not defined
as
a 'char **', you get undefined behavior -- how can the compiler possibly
On Wed, Nov 08, 2006 at 12:47:03PM -0800, David Schwartz wrote:
But it gets cast back to the correct type before it is called. These
casts are done the way they are to get type-safety. Removing that option
strikes me as a bad thing.
It does not. Look closely at how these functions work:
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 two types must be
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 know (through a prototype), you must cast
On Tue, Nov 07, 2006, Bernhard Rosenkraenzer wrote:
gcc 4.2 no longer allows function casting - which is used rather heavily by
openssl. (To make things worse, it compiles but inserts abort() statements
resulting in app crashes).
Ugh, I would've thought that flagging a compiliation error
On Tue, Nov 07, 2006, Bernhard Rosenkraenzer wrote:
gcc 4.2 no longer allows function casting - which is used
rather heavily by
openssl. (To make things worse, it compiles but inserts abort()
statements
resulting in app crashes).
Ugh, I would've thought that flagging a compiliation
34 matches
Mail list logo
