Re: [openssl.org #3424] Misaligned pointers for buffers cast to a size_t*

2014-07-08 Thread Andy Polyakov via RT
As for warning. I personally would argue that we are looking at platform-specific i.e. implementation-defined behaviour, not undefined. Once again, this applies to all three tickets. One is effectively identical to this one, second is about variable shift in CAST. As mentioned they all are

Re: [openssl.org #3424] Misaligned pointers for buffers cast to a size_t*

2014-07-08 Thread noloa...@gmail.com via RT
On Tue, Jul 8, 2014 at 4:33 PM, Andy Polyakov via RT r...@openssl.org wrote: As for warning. I personally would argue that we are looking at platform-specific i.e. implementation-defined behaviour, not undefined. Once again, this applies to all three tickets. One is effectively identical to

Re: [openssl.org #3424] Misaligned pointers for buffers cast to a size_t*

2014-07-08 Thread Andy Polyakov via RT
... if you compile with -fsanitize, you should also add -DPEDANTIC. http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=021e5043e524b1cb28a929ef902548a987c16e65 As mentioned this applies to tickets #3422-4. Looks good to me. Self tests were fine with -DPEDANTIC. Andy - where

Re: [openssl.org #3424] Misaligned pointers for buffers cast to a size_t*

2014-07-08 Thread Jeffrey Walton
On Tue, Jul 8, 2014 at 4:33 PM, Andy Polyakov via RT r...@openssl.org wrote: As for warning. I personally would argue that we are looking at platform-specific i.e. implementation-defined behaviour, not undefined. Once again, this applies to all three tickets. One is effectively identical to

Re: [openssl.org #3424] Misaligned pointers for buffers cast to a size_t*

2014-07-07 Thread David Jacobson
On 7/6/14 1:44 PM, Andy Polyakov via RT wrote: Basically this discussion applies even to tickets #3422 and #3423. This means that I'm not going to comment on those tickets, but do whatever we agree on doing here and close them simultaneously. I think the main question is if this speed

Re: [openssl.org #3424] Misaligned pointers for buffers cast to a size_t*

2014-07-07 Thread Jeffrey Walton
On Sun, Jul 6, 2014 at 6:06 PM, David Jacobson dmjacob...@sbcglobal.net wrote: On 7/6/14 1:44 PM, Andy Polyakov via RT wrote: ... As for warning. I personally would argue that we are looking at platform-specific i.e. implementation-defined behaviour, not undefined. Once again, this applies

Re: [openssl.org #3424] Misaligned pointers for buffers cast to a size_t*

2014-07-07 Thread Peter Waltenberg
d Jacobson dmjacob...@sbcglobal.netFrom: Jeffrey Walton <noloa...@gmail.com> Sent by: owner-openssl-...@openssl.orgDate: 07/07/2014 06:27PM Cc: OpenSSL Developer ML openssl-dev@openssl.orgSubject: Re: [openssl.org #3424] Misaligned pointers for buffers cast to a size_t* On Sun, Jul 6, 2014 a

Re: [openssl.org #3424] Misaligned pointers for buffers cast to a size_t*

2014-07-07 Thread Andy Polyakov
As for warning. I personally would argue that we are looking at platform-specific i.e. implementation-defined behaviour, not undefined. Once again, this applies to all three tickets. One is effectively identical to this one, second is about variable shift in CAST. As mentioned they all are

Re: [openssl.org #3424] Misaligned pointers for buffers cast to a size_t*

2014-07-07 Thread Andy Polyakov via RT
As for warning. I personally would argue that we are looking at platform-specific i.e. implementation-defined behaviour, not undefined. Once again, this applies to all three tickets. One is effectively identical to this one, second is about variable shift in CAST. As mentioned they all are

Re: [openssl.org #3424] Misaligned pointers for buffers cast to a size_t*

2014-07-06 Thread Andy Polyakov via RT
Running `make test` with Clang sanitizers results in some issues with unaligned pointers surrounding some uses of buffers cast to a size_t*. The sanitizers used were `-fsanitize=undefined -fsanitize=address`. Those are conscious choices based on the fact that some CPUs, x86_64 included, are

Re: [openssl.org #3424] Misaligned pointers for buffers cast to a size_t*

2014-07-06 Thread Kurt Roeckx
On Sun, Jul 06, 2014 at 10:25:19AM +0200, Andy Polyakov via RT wrote: Running `make test` with Clang sanitizers results in some issues with unaligned pointers surrounding some uses of buffers cast to a size_t*. The sanitizers used were `-fsanitize=undefined -fsanitize=address`. Those are

Re: [openssl.org #3424] Misaligned pointers for buffers cast to a size_t*

2014-07-06 Thread Andy Polyakov via RT
Running `make test` with Clang sanitizers results in some issues with unaligned pointers surrounding some uses of buffers cast to a size_t*. The sanitizers used were `-fsanitize=undefined -fsanitize=address`. Those are conscious choices based on the fact that some CPUs, x86_64 included, are

Re: [openssl.org #3424] Misaligned pointers for buffers cast to a size_t*

2014-07-06 Thread Kurt Roeckx
On Sun, Jul 06, 2014 at 05:12:42PM +0200, Andy Polyakov via RT wrote: Running `make test` with Clang sanitizers results in some issues with unaligned pointers surrounding some uses of buffers cast to a size_t*. The sanitizers used were `-fsanitize=undefined -fsanitize=address`. Those are

Re: [openssl.org #3424] Misaligned pointers for buffers cast to a size_t*

2014-07-06 Thread Andy Polyakov via RT
... So that above results don't tell anything about benefits of STRICT_ALIGNMENT being undefined. And it's usually around 10%. And indeed, I just measured 12.5% on my computer. [You have to configure with no-asm, and rig apps/speed.c to use misaligned buffers]. If I then turn on strict

Re: [openssl.org #3424] Misaligned pointers for buffers cast to a size_t*

2014-07-06 Thread Kurt Roeckx
On Sun, Jul 06, 2014 at 06:57:57PM +0200, Andy Polyakov via RT wrote: ... So that above results don't tell anything about benefits of STRICT_ALIGNMENT being undefined. And it's usually around 10%. And indeed, I just measured 12.5% on my computer. [You have to configure with no-asm, and rig

Re: [openssl.org #3424] Misaligned pointers for buffers cast to a size_t*

2014-07-06 Thread Andy Polyakov via RT
Basically this discussion applies even to tickets #3422 and #3423. This means that I'm not going to comment on those tickets, but do whatever we agree on doing here and close them simultaneously. I think the main question is if this speed difference is a good excuse to use undefined behavior or