Re: [Mingw-users] Crash in some Win32 environments

[Joerg B. <jo...@sq...>]

Hi Luke!

Luke Dunstan wrote:
> 
> I'm not sure I understand you correctly, but are you saying that you
> dynamically allocate an initial array, then allocate additional blocks
> without freeing or resizing the original array, and treat the separate
> blocks as one array?

Not exactly: The variable is declared as an array with a fixed size, 
so it is statically allocated. When more elements are needed, 
then the additional space is allocated, and from its address the 
index for these elements is computed. (Luckily, C does not do 
array bounds checking.)

All those who say this is a bad design are completely right ;-)

The clean design would use pointers and fully dynamic allocation, 
but the large existing code uses the "array [ index ]" notation 
throughout, even in a nested fashion: "array [ array [ index ]]". 
(The variable in question is a syntax tree, the whole program 
is a Pascal-to-C translator.)
I still try to avoid changing this into pointer notation.

>                   What happens if the second allocation is at a lower
> address than the first? Does your program check for this or do you assume
> that later allocations are at higher addresses?

This is checked against. As the initial array is in the static area 
("bss", in  Unix language), on all platforms encountered till now 
its address is below that of the "calloc"ed space, so the resulting 
index is positive.

If a later dynamic allocation would return lower addresses than a 
previous (dynamic) one, this would just mean lower positive indexes, 
that should not cause any problems.

>                                           I am not saying that this is
> your problem, just that it is probably unreasonable to assume anything about
> where memory will be allocated.

In theory, you are right. 
In practice, I am still surprised that the "Profesional" and the 
"Server" variant of Win2000 behave differently in this area.


Regards,
Joerg Bruehe

-- 
Joerg Bruehe, SQL Datenbanksysteme GmbH, Berlin, Germany
     (speaking only for himself)
mailto: jo...@sq...