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

[Laurence Withers <lwithers@xxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 08 October 2002 12:06, Christer Sandberg wrote:
> Forwarding this since there was no response on the [AL] list:

Christer and Eric, I am sorry, but I'm not subscribed to the [AL] list.

> - 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)

Sorry, I don't understand the change. (That doesn't mean it's wrong :-) 
just that I don't get it). The function new_cident() takes two strings: 
one may be empty (prefix), the other is not empty (name). It allocates 
strlen(prefix) + strlen(name) + 2 bytes, and the final string consists 
of prefix, name, and an underscore and terminating null.

There is definitely a problem here (for me, it only shows up for 7 + 8n 
where n > 0), but it's not in this function because the segfault occurs 
*after* the file has been succesfully output.

I'm trying to find the bug.

> - Truncated glyph data (truncated to 0 size) for mono fonts
>   when using gcc < 3.

Hmm. Why does this happen? Is it because we can't statically initialise 
a zero-sized array or something?

> - 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.

Is this the same thing?

> 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.

I'm afraid this is a huge problem. You can't then use the objects at 
compile time (which is one of the reasons for using dat2c), because the 
exported pointers are not a compile-time constant (the *address* of a 
variable is a compile-time constant, the *value* is not).

> 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).

No, this is because I initialise an array with a string constant, but I 
don't want the terminating zero. AIUI it's perfectly legal to do this 
(although it will of course generate a warning).

> 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

Yes, the *_COUNT identifier should incorporate the datafile name, not 
just the prefix. My bad. When we decide what to do with the above 
problems, we can address this.

Bye for now,
- -- 
Laurence Withers,  lwithers@xxxxxxxxxx
(GnuPG 04A646EA) http://www.lwithers.demon.co.uk/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)

iD8DBQE9o1YVUdhclgSmRuoRAkW/AJ9Jq+N9tXcf1mNUwqXhqCchh5c9kwCfSx1w
eaczKBvpO8plbxpqj6YB+uI=
=LxVn
-----END PGP SIGNATURE-----