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

[Christer Sandberg <christer.sandberg@xxxxxxxxxx>]

At 23:02 2002-10-08 +0100, Laurence Withers wrote:
>> - Too less memory allocated when -p and no -n flag to
>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.
Sounds like your system uses 8byte alignment, doesn't it?
Well, the orignal code of 'do_conversion', which is the
voilating function, allocates strlen(prefix)+5 
for the case mentioned, and concatenates
strlen(prefix)"_""data" which requires one byte more 
including eos. The obvious change would maybe be to 
initialise 'datafile_name' to "data" by default. 
The changes to fix the below problems needed a slightly 
different handling of prefixes, leading to yet one
change in the same statement (unrelated to the memory 
problem).
[The point is to generate a name for static 
variables of an anonymous struct types, this name is
set to be the (eventually) exported name of the pointer
prefixed by an "_", hence the 'name+1' printouts for 
the exported ones.]

>> - Truncated glyph data (truncated to 0 size) for mono fonts...
>Hmm. Why does this happen? Is it because we can't statically initialise 
>a zero-sized array or something?
Yes. If a compiler don't support flexible array members this
simply means that you can't expect it to handle flexible array
members...
A certain compiler may under certain circumstances put 
initialization data in locations that it works anyway 
(gcc 2.96 does this in the case of the bitmaps but not 
in case of the glyph data) but it's not a good idea 
to trust this behaviour for any compiler.

>> - It also fixes the problem with initialization of
>>   bitmaps and rle-sprites, which happens to work..
>Is this the same thing?
Yes, see above. The difference is that I don't
have any compiler that can expose that it is a 
problem.

>> To make these changes possible it was necessary to
>> export pointers instead of the variables themselves,...
>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).
??
Can you give single example of what you can't do using
'p' but you can by using 'global'?
static int local;
int *p=&local;
int global;

>> the last note saying that the user shouldn't
>> worry when the compiler complains about...
>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).
No, on compilers < C99 the warning is because the size of 
initialisation data is > 0. It should be investigated carefully
on C99-compliant compilers too.
char s[]="foo";
This local/global decl assumes eos beeing part of the init data.
Is it really true that flexible array memers in C99 don't 
conform to this convention? I'll have a look at the C99 spec, 
and also try it out on an gcc > 3 compiler.
/C