[PATCH] OpenSSL vs GCC 4.2.0

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[PATCH] OpenSSL vs GCC 4.2.0

Peter Hartley
Hi there,

Having just downloaded GCC 4.2.0 and discovered that it can't build
OpenSSL (not even in the snapshots AFAICT), I'd like to offer a possible
solution.

The earlier thread on openssl-dev explains that OpenSSL chooses to cast
the function pointers, not the parameters, to achieve type-safety; i.e.
to ensure that errors occur if the wrong types are passed to the
XYZ_of() functions.

So how about using expressions of the form
         (void*)(1 ? x : ((T*)NULL))
instead? That way, if x isn't of the right type, GCC will warn because
the ?: gets different types in the two branches. Meanwhile the function
itself is getting called with the correct types, and while OpenSSL is
still "deceiving" the type system, it's doing so only via function
pointers (so there's no way that the compiler, examining any one
translation unit, can "tell" that deception is being attempted). And the
compiler should easily spot that the condition ("1") is always true, and
so generate no extra code compared to the direct, non-typesafe call.

Attached is a patch against SNAP-20070516 which lets all the tests pass
under GCC 4.2.0 (on ia32 and amd64).

        Peter



openssl.diff (11K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] OpenSSL vs GCC 4.2.0

Dr. Stephen Henson
On Tue, May 22, 2007, Peter Hartley wrote:

> Hi there,
>
> Having just downloaded GCC 4.2.0 and discovered that it can't build
> OpenSSL (not even in the snapshots AFAICT), I'd like to offer a possible
> solution.
>
> The earlier thread on openssl-dev explains that OpenSSL chooses to cast
> the function pointers, not the parameters, to achieve type-safety; i.e.
> to ensure that errors occur if the wrong types are passed to the
> XYZ_of() functions.
>
> So how about using expressions of the form
>          (void*)(1 ? x : ((T*)NULL))
> instead? That way, if x isn't of the right type, GCC will warn because
> the ?: gets different types in the two branches. Meanwhile the function
> itself is getting called with the correct types, and while OpenSSL is
> still "deceiving" the type system, it's doing so only via function
> pointers (so there's no way that the compiler, examining any one
> translation unit, can "tell" that deception is being attempted). And the
> compiler should easily spot that the condition ("1") is always true, and
> so generate no extra code compared to the direct, non-typesafe call.
>
> Attached is a patch against SNAP-20070516 which lets all the tests pass
> under GCC 4.2.0 (on ia32 and amd64).
>

Well I'd started using inline functions which add a minimal extra overhead.
That works in a lot of places but can get seriously messy in others.

Would the compiler (or possibly other compilers) give out a warning that a
test was always true?

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Funding needed! Details on homepage.
Homepage: http://www.drh-consultancy.demon.co.uk
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] OpenSSL vs GCC 4.2.0

Peter Hartley
On Wed, 2007-05-23 at 03:07 +0200, Dr. Stephen Henson wrote:
> On Tue, May 22, 2007, Peter Hartley wrote:
> > So how about using expressions of the form
> >          (void*)(1 ? x : ((T*)NULL))
> > instead?
>
> Would the compiler (or possibly other compilers) give out a warning that a
> test was always true?

Well, it's possible I suppose, but compilers I've seen tend to only warn
where it looks like a test is "accidentally" true: unsigned >= 0, that
sort of thing. You can't make the always-trueness of a test any more
deliberate and intentional-looking than by writing "1".

        Peter


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] OpenSSL vs GCC 4.2.0

Dr. Stephen Henson
In reply to this post by Peter Hartley
On Tue, May 22, 2007, Peter Hartley wrote:

> Hi there,
>
> Having just downloaded GCC 4.2.0 and discovered that it can't build
> OpenSSL (not even in the snapshots AFAICT), I'd like to offer a possible
> solution.
>
> The earlier thread on openssl-dev explains that OpenSSL chooses to cast
> the function pointers, not the parameters, to achieve type-safety; i.e.
> to ensure that errors occur if the wrong types are passed to the
> XYZ_of() functions.
>
> So how about using expressions of the form
>          (void*)(1 ? x : ((T*)NULL))
> instead? That way, if x isn't of the right type, GCC will warn because
> the ?: gets different types in the two branches. Meanwhile the function
> itself is getting called with the correct types, and while OpenSSL is
> still "deceiving" the type system, it's doing so only via function
> pointers (so there's no way that the compiler, examining any one
> translation unit, can "tell" that deception is being attempted). And the
> compiler should easily spot that the condition ("1") is always true, and
> so generate no extra code compared to the direct, non-typesafe call.
>
> Attached is a patch against SNAP-20070516 which lets all the tests pass
> under GCC 4.2.0 (on ia32 and amd64).
>

Well I had a chance to test this and it seems OK as far as it goes. It doesn't
however cover all cases. If it can be made to work with -Wall -Werror
-pedantic -DDEBUG_SAFESTACK and possibly a few other options I've forgotten
(the ones in the debug-steve target) that would be great.

I'm buried under other work myself at the moment so haven't had a chance to
extend it myself.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Funding needed! Details on homepage.
Homepage: http://www.drh-consultancy.demon.co.uk
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] OpenSSL vs GCC 4.2.0

Jack Lloyd
In reply to this post by Dr. Stephen Henson
On Wed, May 23, 2007 at 03:07:30AM +0200, Dr. Stephen Henson wrote:

> Would the compiler (or possibly other compilers) give out a warning that a
> test was always true?

Unlikely, that would set off code like:

#define DEBUG 1

[...]

if(DEBUG)
  printf("some debug info");

Which isn't perhaps the best style but a lot of code does get written
like this under the assumption the compiler will detect the trueness
or non-trueness of the expression at compile time and not emit any
code for it. (It also has the advantage that your debug-specific code
will be typechecked, etc, in every build regardless of the value of
DEBUG, unlike the code in an '#if DEBUG' block).

-Jack
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]