Re: [AD] Serious Bugs in the DJGPP port of ALLEGRO in 4.1.17

[Elias Pschernig <elias@xxxxxxxxxx>]

On Mon, 2005-01-10 at 18:46 -0300, Marcio Afonso Arimura Fialho wrote:
[..]
> I've managed to correct most of these problems, and
> the library doesn't seems to crash anymore. The diff
> patches and error reports are attached.

Thanks!

[..]
>    The original files were renamed to xxx.c.orig
> (where xxx is the base name), and the updated files
> remained with the .c extension. After testing the
> changes, I run "diff -u xxx.c.orig xxx.c > xxx.diff"
> (thanks to Daniel Schlyder, who explained me how to
> use diff).

With cvs, you could create the diffs directly against cvs.
(http://awiki.strangesoft.net/bin/view/Main/AllegroDev#Creating_Applying_a_patch) But using diff as you did work just as well.

> 
>   The affected files are:
>      src/dos/dmouse.c => Fix it with dmouse.diff
>      src/dos/vesa.c => Fix it with vesa.diff
>      src/dos/wss.c => I don't know how to fix the
>         warning issued in this file, so I compiled it
>         with the WARNMODE flag OFF.

Hm. The line is:

if (_dma_allocate_mem(BLOCKLEN * 2, &wss_dma_sel, (unsigned long *)&wss_dma_addr) != 0)

And the variable is declared as:

static int wss_dma_addr;

Maybe changing that to static unsigned long fixes it? Not really sure
about this though.. seems to be connected to the 32/64 bit agnostic use
of int/long in allegro, as mentioned recently in another thread.

>      src/misc/modex.c => Fix it with modex.diff
>      src/misc/vbeaf.c => Weird warning. I fixed it
>         making screen_vtable.triangle NULL (not 
>         a very elegant solution).

Simply changing "static int vbeaf_triangle" to "static void
vbeaf_triangle" should fix it as well. The "triangle" function must have
been changed from int to void at some point, although I can't remember
that change.

>   These patches are for the last CVS snapshot (dated
> January 8th).
> 
>    Note: I've delayed to post the diff patches because
> I was doing some tests during my little spare time of
> January 8th and 9th, to make sure these changes didn't
> caused any side effect. Anyway it's a good idea to
> check the patch files before applying them to the
> sources.

They look good, except the 2 issues above.

> 
>   In the build process I used GCC 3.3.4 (at home) and
> GCC 3.4.1 (at work), under a Windows 98 SE DOS box (in
> both machines).

Since you are using windows, you might want to use a windows compiler
instead of DJGPP (although, it would be bad, since again nobody tests
changes with DJGPP then :)

> 
>   Since I'm a newbie to alleg-developers, I would
> appreciate some feedback (eg. it's better to post
> multiple bugs in a sigle thread or each bug in each
> thread).

If they are independent, multiple threads are probably better. But it is
ok for this one. Allegro 4.1.18 (and 4.2.0) hopefully will compile
without problems on djgpp now after the changes are made.

>   Anyway, thanks for this wonderful library. I'm using
> Allegro in a scientific program I'm writing for my
> Master thesis.

What is it about?

-- 
Elias Pschernig