[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
> 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? How about 64bit machines? I guess we haven't asm for
> them, but surely that will be a problem too (some day)?
The problem is that, to read the very last pixel of the BITMAP of
24 bit depth, the asm will read 4 bytes (as it does every pixel),
and the 4th will lie outside the malloc'd area (eg, for every pixel,
it reads an extra byte, which usually happen to be part of the
next pixel, but the last pixel doesn't have a next pixel). That
extra byte is and'd away, but it still reads it.
> Besides, you could comment it better:
Good point, here's a better comment:
> Index: src/graphics.c
> ===================================================================
> RCS file: /cvsroot/alleg/allegro/src/graphics.c,v
> retrieving revision 1.66
> diff -u -p -r1.66 graphics.c
> --- src/graphics.c 12 Nov 2005 16:59:33 -0000 1.66
> +++ src/graphics.c 26 Nov 2005 21:35:38 -0000
> @domain.hidepth
> {
> GFX_VTABLE *vtable;
> BITMAP *bitmap;
> - int i;
> + int padding = 0;
> ASSERT(width >= 0);
> ASSERT(height > 0);
> ASSERT(system_driver);
> @domain.hid_depth
> if (!bitmap)
> return NULL;
>
> - bitmap->dat = malloc(width * height *
BYTES_PER_PIXEL(color_depth));
> + /* This avoids a crash for assembler code accessing the last
pixel, as it read 4 bytes instead of 3. */
> + if (color_depth == 24)
> + padding = 1;
> +
> + bitmap->dat = malloc(width * height * BYTES_PER_PIXEL(color_depth)
+ padding);
> if (!bitmap->dat) {
> free(bitmap);
> return NULL;
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________