On 03.01.2016 15:46, Hanno Böck wrote:
> On Sat, 26 Dec 2015 12:08:12 +0100
> Branko Čibej <brane_at_apache.org> wrote:
>
>> There's a world of difference between invalid memory and uninitialized
>> memory.
> Well, yes, they are different things. Invalid memory is memory not
> allocated. Uninitialized memory is memory that hasn't been assigned a
> value yet. But both are wrong. And in this case it's invalid memory.
>
> Or to make it more specific:
>
> Uninitialized memory:
> int a;
> int b=a;
>
> Invalid memory:
> int a[2]={1,1};
> int b=a[2];
Yes, more or less; although in the case under discussion we're talking
about heap-allocated memory, whereas your examples are either
statically- or stack-allocated. However, I'm sure we are dealing with
uninitialized memory here, not with invalid memory.
>> In this case the memory is both valid (i.e., known to be
>> allocated within the process) and properly aligned. The fact that it
>> may not have been explicitly initialized does not affect the
>> correctness of the code; there's no undefined behaviour being invoked
>> here. The code relies on the fact that the size of allocated buffers
>> is a multiple of the machine word size, which happens to be true for
>> the APR pools we use;
> What you're arguing here is that you're expecting certain architecture
> and compiler specifics. But gcc may decide at any time to break your
> assumptions.
GCC (or any other compiler) may do a lot of things, but it's not allowed
to change the way APR pool allocation works. We're not using malloc();
we're using apr_palloc() & co.
Furthermore, the code is written so that any uninitialized value it
encounters does not affect the correctness of the result. As far as I
can see. (And our test suite would be failing randomly otherwise.)
As I said, you can always define a symbol at compile time to avoid using
that code block.
-- Brane
Received on 2016-01-03 18:12:49 CET