Mail Archives: djgpp/1999/06/10/18:50:57
>> I don't recall what it was called, but it was described as "test sources"
>> and unpacked into a directory called DJGPP/TESTS.
>That'd be the 'djtst202.zip' (or other version number of it), then.
>And no, there's no need to mail it to us: we know it.
Though so..
>> So I gathered. Another weird thing, though: at your request I tried
>> downsizing the source of the program that produces the error, by allocating
>> an char array of the same size in stead of the struct I was using (but
>> leaving everything else, including the typedef, libraries, etc. in place).
>> The error was gone. Here's the change:
>This suggests another, possibly somewhat weird idea: did you actually
>*check* that the size of your structure is 34K, and not something
>else? You should never assume you can calculate the size of a
>structure layed out by gcc, yourself. Ask gcc what size it made it.
Yep. Used sizeof() in the watch window in RHIDE. It's no exactly 34 K, but
the actual source does have the actual amount.
>> // if (rc) rc = ((buffer = malloc(sizeof(bufferType))) != NULL); // old
>> if (rc) rc = ((buffer = malloc(34 * 1024)) != NULL); // new
>> This produces no errors. If I uncomment where I say "// old" and comment
>> away where I say "// new", the error is produced.
>This strongly suggests that the arguments you pass to malloc, here,
>are not really the same, actually.
>> typedef struct {
>> } baseStruct;
>> typedef struct {
>> baseStruct crap1;
>> } firstLevel;
>> typedef struct {
>> firstLevel dcrap2[500];
>> } secondLevel;
>> typedef struct {
>> secondLevel prr[11];
>> } bufferType;
>That's 5500*sizeof(baseStruct), at minimum. Unless there's not more
>than about 6 bytes in there, that's more than 34K, *before* gcc
>puts in any padding.
The first struct is very, very small because there's almost nothing in it
yet (just a single int). I was developing the thing, so I hadn't actually
put in all the members in the struct (some of them are completely empty).
>> As far as I know, this is legal. I.e., I have used it before without any
>> problem, but with another compiler. My current working hypothesis is that
>> there is a problem with this anyway. I am currently thinking of simply
>> ripping the struct apart and allocating it in diffirent variables. Though
>> the endresult - at least in the database I/O - will much much less elegant,
>> I think it may be the only option, as I am starting to suspect this is not
>> all that legal after all..
>It's perfectly legal.
I always thought so..
Anyways, to circumvent the problem, I've ported the bit of code I had to
C++ and made the thing into a class with it's own DB I/O methods. It works
without further problems, so I'll just go on with that. I'd still like to
know the cause of this, though: I hate random and unexplained errors.
Well.. That's the end of another night of programming & E-mail I/O ;-)
Greetz!
Dlanor
- Raw text -