Fwd: Re: [AD] [AL] Problems with dat2c

[Christer Sandberg <christer.sandberg@xxxxxxxxxx>]

Forwarding this since there was no response on the [AL] list:

----------  Vidarebefordrat brev  ----------

Subject: Re: [AL] Problems with dat2c
Date: Sun, 06 Oct 2002 12:36:07 +0200
From: Christer Sandberg <christer.sandberg@xxxxxxxxxx>
To: allegro@xxxxxxxxxx

At 23:30 2002-10-05 +0200, you wrote:
>> I have updated with the most recent cvs of Allegro and tried
>> the dat2c program. I found two problems.
>
>Laurence, did you take a look at these problems ?
>
>--
>Eric Botcazou

Iv'e made a fix that solves the problem, if it can
be to some use.
Attached patch fixes:
- Too less memory allocated when -p and no -n flag to
  dat2c (the bug only shows up when 3+n*4 letters in
  the prefix, due to memory alignment)
- Truncated glyph data (truncated to 0 size) for mono fonts
  when using gcc < 3.
- It also fixes the problem with initialization of
  bitmaps and rle-sprites, which happens to work
  properly with gcc < 3, but is not handled in a
  manner portable for ansi < c99 compilers.
To make these changes possible it was necessary to
export pointers instead of the variables themselves,
in case of -g flag (we can't export variables of
anonymous types). This shouldn't be a big problem
since grabber.txt only says that the identifiers
are visible, not the type of them (and not even
the name). Hopefully not too many uses dat2c yet.

There is also patch removing from grabber.txt
the last note saying that the user shouldn't
worry when the compiler complains about
too long initializers (meaning that data is
truncated).

Finally I can see another problem that I don't
know if it needs to be fixed: I the user
generates multiple datafile and needs to
include more than one of the headers in the same
c-file there will be multiple definitions of
the XX_COUNT identifier. Maybe this is an odd
usage?
/C

Attachment: dat2c.zip
Description: Zip archive