Personally, I have test coverage of the ciphers and hashes we use which deliberately misaligns input and output buffers.
I think we picked up one problem, several years ago.
O.K. someone COULD use a compiler the OpenSSL team doesn't, but frankly test coverage seems the best option. No risk, no performance loss by default.
It's a lot like "the compiler could remove the code we use to scrub keys argument", well, if you suspect that, test for it. Because, seriously, no amount of argument and discussion will resolve it.
Pete
[email protected] wrote: -----
To: David Jacobson <[email protected]>
From: Jeffrey Walton
Sent by: [email protected]
Date: 07/07/2014 06:27PM
Cc: OpenSSL Developer ML <[email protected]>
Subject: Re: [openssl.org #3424] Misaligned pointers for buffers cast to a size_t*
From: Jeffrey Walton
Sent by: [email protected]
Date: 07/07/2014 06:27PM
Cc: OpenSSL Developer ML <[email protected]>
Subject: Re: [openssl.org #3424] Misaligned pointers for buffers cast to a size_t*
On Sun, Jul 6, 2014 at 6:06 PM, David Jacobson <[email protected]> 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 to all three tickets. One is effectively
>> identical to this one, second is about variable shift in CAST. As
>> mentioned they all are conscious choices and are proven to work. BTW,
>> specification gives following example of undefined behaviour:
>>
>> "EXAMPLE: An example of undefined behavior is the behavior on integer
>> overflow."
> ...
> According to C99 overflow/wrapping of unsigned integer values is defined to
> be modulo the range of the type. Here are the quotes:
>
> For conversions, Section 6.3.1.3 paragraph 2:
>
> 2 Otherwise, if the new type is unsigned, the value is converted by
> repeatedly adding or subtracting one more than the maximum value that can be
> represented in the new type until the value is in the range of the new
> type.49)
>
> For binary operators, Section 6.2.5 paragraph 9:
>
> A computation involving unsigned operands can never overflow, because a
> result that cannot be represented by the resulting unsigned integer type is
> reduced modulo the number that is one greater than the largest value that
> can be represented by the resulting type.
>
> The "EXAMPLE: ..." quote above is incorrect since, only overflow of _signed_
> integers results in undefined behavior.
I think the paragraph of interest for the Clang finding is 6.3.2.3,
paragraph 7 [ISO/IEC 9899:2011]:
A pointer to an object or incomplete type may be
converted to a pointer to a different object or
incomplete type. If the resulting pointer is not
correctly aligned for the referenced type, the
behavior is undefined.
I could be wrong because I am not a C language expert. I generally use
a tool to help me spot transgressions and then fix them (once pointed
out, I usually understand them).
I think Andy is right with respect to processor behavior. But I'm not
certain if its the best strategy given the C langauge rules.
Jeff
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
>> 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 to all three tickets. One is effectively
>> identical to this one, second is about variable shift in CAST. As
>> mentioned they all are conscious choices and are proven to work. BTW,
>> specification gives following example of undefined behaviour:
>>
>> "EXAMPLE: An example of undefined behavior is the behavior on integer
>> overflow."
> ...
> According to C99 overflow/wrapping of unsigned integer values is defined to
> be modulo the range of the type. Here are the quotes:
>
> For conversions, Section 6.3.1.3 paragraph 2:
>
> 2 Otherwise, if the new type is unsigned, the value is converted by
> repeatedly adding or subtracting one more than the maximum value that can be
> represented in the new type until the value is in the range of the new
> type.49)
>
> For binary operators, Section 6.2.5 paragraph 9:
>
> A computation involving unsigned operands can never overflow, because a
> result that cannot be represented by the resulting unsigned integer type is
> reduced modulo the number that is one greater than the largest value that
> can be represented by the resulting type.
>
> The "EXAMPLE: ..." quote above is incorrect since, only overflow of _signed_
> integers results in undefined behavior.
I think the paragraph of interest for the Clang finding is 6.3.2.3,
paragraph 7 [ISO/IEC 9899:2011]:
A pointer to an object or incomplete type may be
converted to a pointer to a different object or
incomplete type. If the resulting pointer is not
correctly aligned for the referenced type, the
behavior is undefined.
I could be wrong because I am not a C language expert. I generally use
a tool to help me spot transgressions and then fix them (once pointed
out, I usually understand them).
I think Andy is right with respect to processor behavior. But I'm not
certain if its the best strategy given the C langauge rules.
Jeff
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
