Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: two objects in global scope have the same name |
| Date | 2011-06-18 10:33 -0400 |
| Organization | A noiseless patient Spider |
| Message-ID | <itid0a$i4g$1@dont-email.me> (permalink) |
| References | <itfvi6$t8f$1@speranza.aioe.org> <chine.bleu-D062AE.20523717062011@news.eternal-september.org> <iti716$ams$1@speranza.aioe.org> |
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
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
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
csiph-web