On Thu, Oct 18, 2007 at 04:25:10PM +0100, Frank Hofmann wrote:
> On Thu, 18 Oct 2007, Ceri Davies wrote:
> 
> [ ... ]
>> Hmm, you're right, I think I've misparsed the rest of the sentence
>> Part of the figure is:
>> 
>>  0x70a9add8: deadbeef deadbeef \
>>  0x70a9ade0: deadbeef deadbeef +- User Data (free)
>>  0x70a9ade8: deadbeef deadbeef /
>>  0x70a9adf0: feedface feedface -- REDZONE
>>  0x70a9adf8: 70ae3260 8440c68e -- Debugging Data
>> 
>> Followed by the text:
>> 
>>  In the free buffers at 0x70a9add8 and 0x70a9ae28, the redzone is filled
>>  with 0xfeedfacefeedface. This a convenient way of determining that a
>>  buffer is free.
>> 
>> I read that incorrectly; apologies for the noise.
> 
> Ok, now I see what you mean, and you're right it's not optimal.
> 
> Maybe the text should be augmented to read:
> 
>       The buffers at 0x70a9add8 and 0x70a9ae28 are filled with
>       0xdeadbeefdeadbeef, which conveniently shows that they are free.
>       The buffer redzones are filled with 0xfeedfacefeedface, which
>       indicates they're untouched (no buffer overrun has happened).
> 
> Or similar. Now that you've given the text sample, I see where the 
> confusion could come in. It's indeed so that the "This is a convenient way 
> ..." part is not quite correct because the 'buffer is free' markers are 
> deadbeef. Pristine redzones are an indicator of 'buffer limits were 
> respected', not 'buffer is free'.
> 
> If one wants to explain the marker patterns in a simple list, one could 
> say:
> 
>       0xbaddcafe:     'buffer is allocated but uninitialized'
>       0xdeadbeef:     'buffer is free'
>       0xfeedface:     'buffer limits were respected' (no overflow)

Thank you for clarifying, Frank; I was sure there was something up with
the previous text.

Ceri
-- 
That must be wonderful!  I don't understand it at all.
                                                  -- Moliere
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: 
<http://mail.opensolaris.org/pipermail/docs-discuss/attachments/20071018/a0032709/attachment.bin>

Reply via email to