On 03.01.2016 15:46, Hanno Böck wrote:
> On Sat, 26 Dec 2015 12:08:12 +0100
> Branko Čibej <br...@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
