Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #6254 > unrolled thread

two objects in global scope have the same name

Back to article view | Back to comp.lang.c

Contents

  two objects in global scope have the same name "Mark" <mark_cruzNOTFORSPAM@hotmail.com> - 2011-06-17 12:32 -0400
    Re: two objects in global scope have the same name Shao Miller <sha0.miller@gmail.com> - 2011-06-17 13:08 -0500
    Re: two objects in global scope have the same name pete <pfiland@mindspring.com> - 2011-06-17 23:10 -0400
      Re: two objects in global scope have the same name Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-06-17 23:43 -0600
        Re: two objects in global scope have the same name James Kuyper <jameskuyper@verizon.net> - 2011-06-18 10:16 -0400
    Re: two objects in global scope have the same name China Blue Angels <chine.bleu@yahoo.com> - 2011-06-17 20:52 -0700
      Re: two objects in global scope have the same name "Mark" <mark_cruzNOTFORSPAM@hotmail.com> - 2011-06-18 08:51 -0400
        Re: two objects in global scope have the same name James Kuyper <jameskuyper@verizon.net> - 2011-06-18 10:33 -0400
          Re: two objects in global scope have the same name "Mark" <mark_cruzNOTFORSPAM@hotmail.com> - 2011-06-19 14:07 -0400
            Re: two objects in global scope have the same name James Kuyper <jameskuyper@verizon.net> - 2011-06-20 06:36 -0400
        Re: two objects in global scope have the same name China Blue Angels <chine.bleu@yahoo.com> - 2011-06-18 08:12 -0700

#6254 — two objects in global scope have the same name

Hello,

consider the following snippet:

struct foo_struct {
   int a;
   int b;
};

struct foo_struct *foo;
struct foo_struct foo_global;

int foo(int x)
{
  ....
  return 0;
}

int main(void)
{
   foo = &foo_global;
  ...
}

So I have two identifiers but for diferent objects (is it correct to call 
function as object?).  Is this stricly illegal, or the standard defines such 
case as "undefined behavior". What part of the standard describe this?

Thanks.

[toc] | [next] | [standalone]

#6257

On 6/17/2011 11:32 AM, Mark wrote:
> Hello,
>
> consider the following snippet:
>
> struct foo_struct {
>     int a;
>     int b;
> };
>
> struct foo_struct *foo;

Above, the file-scope[6.2.1p4] 'foo' is declared as an object with type 
'struct foo_struct *'.

> struct foo_struct foo_global;
>
> int foo(int x)
> {
>    ....
>    return 0;
> }
>

Above, the file-scope 'foo' is declared as a function taking an 'int' 
argument and returning an 'int' value.  This is not compatible with the 
earlier declaration.

> int main(void)
> {
>     foo =&foo_global;
>    ...
> }
>
> So I have two identifiers but for diferent objects (is it correct to call
> function as object?).  Is this stricly illegal, or the standard defines such
> case as "undefined behavior". What part of the standard describe this?

6.2.1p4 includes:

   "... If an identifier designates two different entities in the same 
name space, the scopes might overlap. If so, the scope of one entity 
(the inner scope) will be a strict subset of the scope of the other 
entity (the outer scope). ..."

This criteria is not met by your file-scope declarations for 'foo'.

[toc] | [prev] | [next] | [standalone]

#6330

Mark wrote:
 
> So I have two identifiers but for diferent objects
> (is it correct to call function as object?).  

A function is not an object.

-- 
pete

[toc] | [prev] | [next] | [standalone]

#6337

pete <pfiland@mindspring.com> writes:

> Mark wrote:
>  
>> So I have two identifiers but for diferent objects
>> (is it correct to call function as object?).  
>
> A function is not an object.

While technically you are correct, I think you probably understood what
he actually meant.

[toc] | [prev] | [next] | [standalone]

#6355

On 06/18/2011 01:43 AM, Joe Pfeiffer wrote:
> pete <pfiland@mindspring.com> writes:
> 
>> Mark wrote:
>>  
>>> So I have two identifiers but for diferent objects
>>> (is it correct to call function as object?).  
>>
>> A function is not an object.
> 
> While technically you are correct, I think you probably understood what
> he actually meant.

He also explicitly asked whether the term was correct, and pete answered
that question.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#6331

In article <itfvi6$t8f$1@speranza.aioe.org>,
 "Mark" <mark_cruzNOTFORSPAM@hotmail.com> wrote:

> Hello,
> 
> consider the following snippet:
> 
> struct foo_struct {
>    int a;
>    int b;
> };
> 
> struct foo_struct *foo;
> struct foo_struct foo_global;
> 
> int foo(int x)

You can't define the same name with two different types in the same scope.

You shouldn't define the same external name with different types in different 
source files, but not all compilers and loaders will catch this.

-- 
I remember finding out about you,  |              I survived XYZZY-Day.
Everyday my mind is all around you,|     I'm whoever you want me to be.
Looking out from my lonely room    |Annoying Usenet one post at a time.
Day after day.                     |  At least I can stay in character.

[toc] | [prev] | [next] | [standalone]

#6352

Hi,

"China Blue Angels" <chine.bleu@yahoo.com> wrote in message 
news:chine.bleu-D062AE.20523717062011@news.eternal-september.org...
>> struct foo_struct *foo;
>> struct foo_struct foo_global;
>>
>> int foo(int x)
>
> You can't define the same name with two different types in the same scope.
>
It's clear for me now, thanks.

> You shouldn't define the same external name with different types in 
> different
> source files, but not all compilers and loaders will catch this.
>

Could you elaborate on this statement, what can go wrong ? What does the 
standard say about such case?

So, if I understand you correctly, this should not happen:

a.h:
extern int x;

a.c:
#include "a.h"
int x;

b.h:
extern long x;

b.c:
#include "b.h"
long x;

So If later I link both object files a.o and b.o into target exeecutable, 
and if linker can't catch this, it's possible that compiler may generate 
code so that long vale will be assigned to integer object?  Please clarify 
my doubts.

Thanks in advance ! 

[toc] | [prev] | [next] | [standalone]

#6357

On 06/18/2011 08:51 AM, Mark wrote:
> Hi,
> 
> "China Blue Angels" <chine.bleu@yahoo.com> wrote in message 
> news:chine.bleu-D062AE.20523717062011@news.eternal-september.org...
...
>> You shouldn't define the same external name with different types in 
>> different
>> source files, but not all compilers and loaders will catch this.
>>
> 
> Could you elaborate on this statement, what can go wrong ? What does the 
> standard say about such case?

6.9p5:
> ... If an identifier declared with external
> linkage is used in an expression (other than as part of the operand of a sizeof operator
> whose result is an integer constant), somewhere in the entire program there shall be
> exactly one external definition for the identifier; otherwise, there shall be no more than
> one.

Those "shall"s occur outside of a constraint section. Code which
violates them therefore has undefined behavior (4p2). That means that
the C standard imposes no requirements on what the implementation does
with your code. In principle, that means that just about anything can
happen.

In practice, if the linker even accepts such code, one common
possibility is that both definitions will share overlapping pieces of
memory, as if they were in a union with each other. Another possibility
is that they are stored in completely different pieces of memory. A
third possibility is that they are assigned to a piece of memory that's
only big enough to store the smaller type, and that any attempt to read
or write using the definition with the larger type will attempt to
access memory allocated for some other use, generally with catastrophic
consequences.

> So, if I understand you correctly, this should not happen:

More precisely, this should not be done. It can quite easily happen.

> a.h:
> extern int x;
> 
> a.c:
> #include "a.h"
> int x;
> 
> b.h:
> extern long x;
> 
> b.c:
> #include "b.h"
> long x;
> 
> So If later I link both object files a.o and b.o into target exeecutable, 
> and if linker can't catch this, it's possible that compiler may generate 
> code so that long vale will be assigned to integer object?

That's among the least likely of the possibilities, but it is also
technically possible.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#6456

Hello
Thanks a lot for comments.

"James Kuyper" <jameskuyper@verizon.net> wrote in message 
news:itid0a$i4g$1@dont-email.me...
> 6.9p5:
>> ... If an identifier declared with external
>> linkage is used in an expression (other than as part of the operand of a 
>> sizeof operator
>> whose result is an integer constant), somewhere in the entire program 
>> there shall be
>> exactly one external definition for the identifier; otherwise, there 
>> shall be no more than
>> one.
>
> Those "shall"s occur outside of a constraint section. Code which
> violates them therefore has undefined behavior (4p2). That means that
> the C standard imposes no requirements on what the implementation does
> with your code. In principle, that means that just about anything can
> happen.
>

Consider this snippet:

a.h:
extern int x;

a.c:
#include "a.h"
int x;

b.h:
extern long x(void);

b.c:
#include "b.h"
long x(void)
{
   return 1;
}

How does the Standard interpret this case?  I think that 6.9.1p6 applies to 
this case, and results in underfined behavior as well ?

Thanks. 

[toc] | [prev] | [next] | [standalone]

#6501

On 06/19/2011 02:07 PM, Mark wrote:
> Hello
> Thanks a lot for comments.
> 
> "James Kuyper" <jameskuyper@verizon.net> wrote in message 
> news:itid0a$i4g$1@dont-email.me...
>> 6.9p5:
>>> ... If an identifier declared with external
>>> linkage is used in an expression (other than as part of the operand of a 
>>> sizeof operator
>>> whose result is an integer constant), somewhere in the entire program 
>>> there shall be
>>> exactly one external definition for the identifier; otherwise, there 
>>> shall be no more than
>>> one.
>>
>> Those "shall"s occur outside of a constraint section. Code which
>> violates them therefore has undefined behavior (4p2). That means that
>> the C standard imposes no requirements on what the implementation does
>> with your code. In principle, that means that just about anything can
>> happen.
>>
> 
> Consider this snippet:
> 
> a.h:
> extern int x;
> 
> a.c:
> #include "a.h"
> int x;
> 
> b.h:
> extern long x(void);
> 
> b.c:
> #include "b.h"
> long x(void)
> {
>    return 1;
> }
> 
> How does the Standard interpret this case?  I think that 6.9.1p6 applies to 
> this case, and results in underfined behavior as well ?

?
6.9.1p6 is about function declarations with identifier lists, also known
as K&R style declarations. Example:

	oldfunc(a, b)
		char a;
		double b;
	{
	     return a+b;
	}

They were quickly abandoned shortly after the concept of function
prototypes was introduced. Nowadays they are generally found only in
legacy code and obfuscated C contests; there are none in your example.

The clause I cited was 6.9p5. It defines the term "external definition",
to include definitions of either functions or objects. The "shall"
statements in that clause are about "external definitions". Note,
however, that your code does not yet meet the conditions needed to have
undefined behavior. You have not actually created a single program
containing both translation units. Even if you did, that program does
not yet contain any code which actually uses 'x'. Until you add such
code, the first "shall" in 6.9p5 has not yet been violated.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#6363

In article <iti716$ams$1@speranza.aioe.org>,
 "Mark" <mark_cruzNOTFORSPAM@hotmail.com> wrote:

> Hi,
> 
> "China Blue Angels" <chine.bleu@yahoo.com> wrote in message 
> news:chine.bleu-D062AE.20523717062011@news.eternal-september.org...
> >> struct foo_struct *foo;
> >> struct foo_struct foo_global;
> >>
> >> int foo(int x)
> >
> > You can't define the same name with two different types in the same scope.
> >
> It's clear for me now, thanks.
> 
> > You shouldn't define the same external name with different types in 
> > different
> > source files, but not all compilers and loaders will catch this.
> >
> 
> Could you elaborate on this statement, what can go wrong ? What does the 
> standard say about such case?
> 
> So, if I understand you correctly, this should not happen:
> 
> a.h:
> extern int x;
> 
> a.c:
> #include "a.h"
> int x;
> 
> b.h:
> extern long x;
> 
> b.c:
> #include "b.h"
> long x;
> 
> So If later I link both object files a.o and b.o into target exeecutable, 
> and if linker can't catch this, it's possible that compiler may generate 
> code so that long vale will be assigned to integer object?  Please clarify 
> my doubts.

If long and int are different sizes, different compilation units are going to 
load and store a different number of bytes. Depending on the loader, it might 
allocate the maximum size or the first size, last size, whatever. That could 
lead to storing outside the allocation.

A loader might also allow x to be a function name in one compilation unit and 
variable in another resulting in unamusing bugs.

-- 
I remember finding out about you,  |              I survived XYZZY-Day.
Everyday my mind is all around you,|     I'm whoever you want me to be.
Looking out from my lonely room    |Annoying Usenet one post at a time.
Day after day.                     |  At least I can stay in character.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web