Re: [AD] Possible bug in 4.2 bitmap loading code.

["David Capello" <davidcapello@xxxxxxxxxx>]

On Sun, Mar 23, 2008 at 9:28 PM, Peter Wang <novalazy@xxxxxxxxxx> wrote:
>  I am not sure why biHeight is left as an `unsigned long'.  Shouldn't it just be
>  changed to `signed long' and then we can get rid of the int casts?

OK, I put it as a 'signed long' in BITMAPINFOHEADER and WINBMPINFOHEADER
(OS/2 can't be negative, so it stays as an 'unsigned short').

Attached the new patch that fix problems to load
bitmaps from the bmp-suite of Jason Summers.

 http://www.dacap.com.ar/bmpbug2.zip

>  A glance at the bmp.c code shows that it's very trusting of the source file.
>  Anybody feel like fixing it? (or any of the other loaders)

Yes, that's right, it looks like the files should be perfect.
Anyway, I think that it's not a big problem for Allegro as a
library to program games. It is supposed that you should
check that your files aren't corrupted before to load them
with Allegro (anyway, the user/player could modify them).

On the other hand, I'm worry about it because Allegro Sprite
Editor (ASE) uses (a modified version of) these routines, and
in an editing program it's really important to check any problem
that could appears in the files.

By now, I'm not planning to put more constraints in the Allegro
routines (because I'll be working on ASE). Also I think that the
code will look too much complex (with a lot of conditions,
"return"s and maybe some "goto" :)

There are another issue, MSDN says that an BMP can't be
'top-down' and 'compressed' at the same time, but with Adobe
Photoshop you can create them (RLE4 or RLE8, with negative
height). ¿We should give support to load these top-down
compressed files? I think that most programs don't support
these odd files.

Attachment: bmp.c.diff
Description: Binary data