Path: utzoo!attcan!utgpu!watmath!clyde!att!pacbell!lll-tis!helios.ee.lbl.gov!ux1.lbl.gov!forrest
From: forrest@ux1.lbl.gov (Jon Forrest)
Newsgroups: comp.sys.ibm.pc
Subject: Possible Bug in Turbo Linker (and question about Turbo Debug)
Message-ID: <1254@helios.ee.lbl.gov>
Date: 13 Nov 88 04:39:20 GMT
Sender: usenet@helios.ee.lbl.gov
Organization: Lawrence Berkeley Laboratory, Berkeley
Lines: 38

I've been doing some playing around with Turbo C 2.0 and I have
found something that I didn't expect. This is the fact that
if you declare the same external variable in more than one file,
the linker treats them as separate variables instead of treating
them as references to the same variable. You can see this be
creating 2 files, each with "int x" as the first line. Compile
them and link them. You'll see an error message from the linker
saying "Error: x defined in module YYY is duplicated in module ZZZ"
(where YYY and ZZZ are the names of the files). Furthermore, if you
run OBJXREF /RC you see that "_x" exists in both object files
and uses space in both. Another way to prove this is to define
a 60K byte array the same way. Then, when you link, in addition
to getting the error message I mentioned above, you'll also get
an error message complaining about a BSS segment that is greater
than 64K since the two references add up to more than 64K. On the other
hand, if you say "extern int x" in all but one of the files referencing
"x", and then "int x" in just one file, then everything works OK.
Needless to say, this is a pain when such definitions are done in an
#include file.

The reason I think this is wrong, in additon to being different
than the behavior on Unix and VMS, is that K&R (1st edition)
on page 206, section 11.1 says "... all references to the same
external identifier refer to the same object ...". Note that
this is not a flame. If this is the way ANSI C is supposed to
work then this is fine with me, although there will probably
be lots of people who'll end up fighting with this.

The question about the Debugger (either standalone or integrated)
is how to gain control when a null pointer is dereferenced.
The compiler generates a nice check for this but when this happens
the program immediatly exits. I'd like to gain control in the
debugger so that I can find out what went wrong. I didn't see
how to do this in my first reading of the manual.
Jon Forrest		Lawrence Berkeley Lab., 486-4991
forrest@lbl.gov			(internet)
ucbvax!lbl-csam!ux1!forrest	(uucp)
FORREST@LBL			(bitnet)