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
> 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 expect
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.
> 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 pr
>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 x509fun
> 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 doe
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 compatibl
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 K&R C, you couldn't cast t
> 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 *'
On 11/9/06, David Schwartz <[EMAIL PROTECTED]> wrote:
> Once K&R 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
> Once K&R 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
> 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
K&R rules. If a function wil
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
> > 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
> >
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
> 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.
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 char
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
> 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> si
com> To
Sent by:
owner-openssl-dev cc
@openssl.org
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 s
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
>
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 mus
> 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
pa
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 functio
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 po
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 wor
CTED]>
Sent by: [EMAIL PROTECTED]
09/11/2006 06:47 AM
Please respond to
openssl-dev
To
cc
Subject
RE: OpenSSL 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 tha
> 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,
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 cra
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
u
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
> 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 co
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 err
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).
You can see http://gcc.gnu.org/ml/gcc/2006-07/msg00037.html
for a discussion on the gcc devel list.
Is there a fix t
35 matches
Mail list logo
