[comp.sys.ibm.pc] Bug in link - I think there's something to this!

jeff@ducall.UUCP (03/13/87)

[]

Someone wrote recently about a problem with static arrays declared in
different modules.  Amazing cooincidence, I just came across the same
type of problem with a static array in one module and malloced memory
in another.  

The code goes something like the following.  The compiler is Microsoft
C.  Procedures foo and bar are in different files.  Both are compiled
using the large memory model.  They are two procedures in a rather large
application, consisting of roughly 20 files and 200 procedures.

struct BAR *first_link;

foo()
{
	char *malloc();
	struct BAR *next_link;

	first_link = (struct BAR *)malloc(sizeof(struct BAR));
	next_link = first_link;
	while (!done) {
		next_link->next = (struct BAR *)malloc(sizeof(struct BAR));
		next_link = next_link->next;
	}
}

bar()
{
	static char my_strings[10][128];
	int i;

	for (i = 0; i < 128; i++)
		strcpy(my_strings[i],"STUNKY FLUFF\n");
}

I am using the large memory model (I don't know if the problem persists
in other models).  The MSC User's Guide implies that the compiler puts
my_strings in a _BSS segment.  When I run the program procedure foo
allocates memory, and runs right over the area that should have been
reserved for my_strings.  When bar executes, of course, the list structure
is destroyed, as well as their contents, and the memory management info
(i.e. program crashes in spectacular flames).

As was the experience with the former observer, when I initialize my_strings
the problem goes away - obviously because the compiler moves the array from
the BSS section to the (initialized) data segment.  This, however, is a
kludge not a solution!  Am I doing something wrong, or is there a bug in
MSC malloc() such that (at least in the large memory model) one cannot
have uninitialized global or static data.


-- 
Jeffrey William Gillette          uucp: mcnc!ethos!ducall!jeff 
Humanities Computing Facility     bitnet: DYBBUK at TUCCVM
Duke University

vizard@dartvax.UUCP (Todd Krein) (03/19/87)

In article <373@ducall.UUCP>, jeff@ducall.UUCP (Jeffrey William Gillette ) writes:
> []
> 
> Someone wrote recently about a problem with static arrays declared in
> different modules.  Amazing cooincidence, I just came across the same
> type of problem with a static array in one module and malloced memory
> in another.  
> 
> The code goes something like the following.  The compiler is Microsoft
> C.  

	[rest deleted]

	Yup, there's a bug in link.... Found another one like it...


code:

extern	float	x[2000];
	float	x[2000];
main(){
 .
 .
 .
}

file 2 code:

extern	float	x[2000];

fred(){
 .
 .
 .
}

Now the kicker.... I'm using a third party library (gasp, choke) which, I
just discovered, declared x as an external integer! One might think that
since the obj files define the length of the external variables, that the
linker would complain about multiple def's and die. Nope, it sets x as an 
integer, and I go merrily writing over my variable space.....

	I'm also using MSC 4.0, and the libraray was (I'm told) done
with MSC 3.0.

Anyone got a fix for this?

		Todd Krein
		vizard@dartvax