This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Redeclaration of used symbols


"Zack Weinberg" <zack@codesourcery.com> writes:

| Jan Hubicka <hubicka@ucw.cz> writes:
| 
| > Hi,
| > We currently accept the following testcase:
| >
| > t()
| > {
| > }
| > static int t();
| > b()
| > {
| > 	t();
| > }
| >
| > when compiled with -fPIC we get an global symbol t that is called as if
| > it were local symbol in non-PIC way on i386.  I believe we get similar
| > misscompilations on most of other targets as well as confussion of the
| > unit-at-a-time code and such.
| >
| > Is this valid C?
| 
| No, it's undefined behavior - t is declared in the same scope with two
| different linkages.  (6.2.2p7)

That is to be contrasted with:
6.2.2/4
       [#4]  For  an  identifier  declared  with  the storage-class
       specifier extern in a scope in which a prior declaration  of
       that identifier is  visible,23)  if  the  prior  declaration
       specifies  internal  or external linkage, the linkage of the
       identifier at the later  declaration  is  the  same  as  the
       linkage  specified  at  the  prior declaration.  If no prior
       declaration  is  visible,  or  if  the   prior   declaration
       specifies  no  linkage,  then  the  identifier  has external
       linkage.

thus an identifier can be declared "static" or "extern" and later
redeclared "extern", the first linkage declaration wins.

But I agree that the other way around is undefined behaviour as per
6.2.2/7.  It can be diagnosed and I too will suggest a hard error.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]