Date: Tue, 8 Dec 1998 15:04:59 +1030 From: Greg Lehey <grog@lemis.com> To: jobaldwi@vt.edu, freebsd-chat@FreeBSD.ORG Subject: Re: gcc and dup variables... Message-ID: <19981208150459.Q12688@freebie.lemis.com> In-Reply-To: <XFMail.981207232041.jobaldwi@vt.edu>; from John Baldwin on Mon, Dec 07, 1998 at 11:20:41PM -0500 References: <XFMail.981207232041.jobaldwi@vt.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Is this -chat material? Yes, I know, everything's -chat material, but
it seems to me that this is one that could have been handled in a
technical forum.
On Monday, 7 December 1998 at 23:20:41 -0500, John Baldwin wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
>
> I just ran into a rather weird little oddity.
>
> I'm working on a C project, and in one module, I have a private variable
> declared as so:
>
> FILE *dbaseFile;
>
> In another module, I have a private variable as such:
>
> char *dbaseFile;
If you write them like that, they're not private (static), they're
global.
> It seems that ld has merged these two references into the same
> thing,
This is a feature, not a bug.
> with some rather interesting side effects when I tried to print the
> string out after opening the file.
Indeed :-)
> I would've thought that I would have gotten a linker
> error for duplicate symbols of conflicting types, but I guess that ld treats
> all pointers the same as it doesn't know types? But, I also thought that if
> two modules both had non-external vars of the same name ld should've flagged
> that instead of silently merging the two. So a) is this how ld is supposed to
> work
Yes.
> and b) if so, why?
Because nobody ever got round to defining arbitrary types for the C
linker. They did it for C++ functions with name mangling, but that's
a whole different can of worms. Unfortunately, C++ won't catch this
particular problem either: from the ARM, section 7.3c:
Types of variables are not encoded in their names, nor are the
return types of functions encoded. This makes it impossible to
catch errors like these:
// file 1:
extern int a;
int f() { return a };
// file 2:
float a;
extern float f();
> I can see how if one was two lazy to declare variables extern
> everywhere but once that this would be helpful, but I'd rather ld
> give me a link error as it can lead to some interesting bugs.
This is one of the reasons why people like Bruce snoop around and put
'static' in front of every variable which will take it.
Greg
--
See complete headers for address, home page and phone numbers
finger grog@lemis.com for PGP public key
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19981208150459.Q12688>