[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
- To: alleg-developers@xxxxxxxxxx
- Subject: Re: [AD] bug in getpixel
- From: Chris <chris.kcat@xxxxxxxxxx>
- Date: Sat, 26 Nov 2005 15:07:27 -0800
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:date:user-agent:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; b=JQ3W1u66T2aj0p7lLj4RyW0BzjLljd8kmm3wHFHa45Dzgdp3XhUvC8fMufSpSqG+jk61vTi0MLsJ0kqPPQxgrz+x4/40DQtDbkVAD0wGr5XYfzeRYX3IkXL8rCvxY5zv8Ul/+UscmtUTl+qjdltVyiE/SxUue8pW8PPbAR+umGo=
On Saturday 26 November 2005 01:37 pm, Grzegorz Adam Hankiewicz wrote:
> I don't understand the rationale behind adding just one byte. Say
> I wanted a bitmap of 3x1 pixels, which will malloc 3 * 1 * 3 =
> 9 bytes. Adding one makes it 10, but wouldn't alignment rules
> require 12?
Not really, since reading the first and second pixel would overread into the
first byte of the second and third pixel (which would then be masked out).
It's only the last pixel that needs the extra padding.
xxx xxx xxx
\___/ - first pixel read
xxx xxx xxx
\___/ - second pixel read
xxx xxx xxx *
\___/ - third pixel read
> How about 64bit machines?
As long as you only read 4 bytes (with uint32_t) that won't matter.