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>