Mail Archives: djgpp/1999/09/02/05:43:37
to comp.os.msdos.djgpp <axlq AT unicorn DOT us DOT com> wrote in message
news:7qjgcl$hmt$1 AT samba DOT rahul DOT net...
> Problem solved! Thanks Eli, who told me about symify, and thanks
> Michael, who shared his identical experience, and the solution:
>
> From: Michael Bukin <M DOT A DOT Bukin AT inp DOT nsk DOT su>
> Date: 01 Sep 1999 21:13:35 +0700
>
> I recall that I had similar problem while porting one application.
> Implementation of malloc in djgpp-2.02 defines global array "freelist"
> which keeps some internal state of malloc. If you have the same
> global symbol in your code, your program may crash when malloc
> dereference this array.
DJ, another solution is for the next DJGPP release's malloc()
to keep its freelist in some global upon which the average
programmer is not likely to stumble:
FooRec *_malloc_freelist;
> One solution is to replace all references to global symbol "freelist"
> in your code with something else, or make "freelist" static. If you
> don't have global symbol "freelist", then, IIRC, there are other
> global symbols defined in malloc.
A way to avoid global variable conflicts, borrowed from Macintosh
programming books, is to name all your globals starting with a g:
int gFoo;
int gFreelist;
Another technique, which I used in DOSArena, is to
place all your global data in a structure:
typedef struct Globals
{
int foo;
} Globals;
Globals g;
int bar(void)
{
g.foo = 1;
}
A C++ variation on this technique also allows multiple instances.
Damian Yerrick
http://come.to/yerrick
- Raw text -