Asp Forum - two objects in global scope have the same name

Mark

6/17/2011 4:32:00 PM

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.

11 Answers

ram

6/17/2011 4:54:00 PM

"Mark" <mark_cruzNOTFORSPAM@hotmail.com> writes:
>So I have two identifiers

two declarations, one identifier

>but for diferent objects

for »different entities«.

In 6.2.3, ISO/IEC 9899:1999 (E) defines four name spaces.
According to this, that two declarations both declare
a name in the same name space of ordinary identifiers.

Shao Miller

6/17/2011 6:08:00 PM

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'.

pete

6/18/2011 3:10:00 AM

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

China Blue Veins

6/18/2011 3:53:00 AM

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.

Joe Pfeiffer

6/18/2011 5:44:00 AM

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.

Mark

6/18/2011 12:52:00 PM

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 !

James Kuyper

6/18/2011 2:17:00 PM

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

James Kuyper

6/18/2011 2:34:00 PM

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

China Blue Veins

6/18/2011 3:12:00 PM

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.

Mark

6/19/2011 6:08:00 PM

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.

comp.lang.c

two objects in global scope have the same name

Mark

ram

Shao Miller

pete

China Blue Veins

Joe Pfeiffer

Mark

James Kuyper

James Kuyper

China Blue Veins

Mark

x Login to ForumsZone