Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Struct assignment |
| Date | 2013-01-19 11:25 -0500 |
| Organization | A noiseless patient Spider |
| Message-ID | <kdehee$3ni$1@dont-email.me> (permalink) |
| References | <u0fqs9-929.ln1@main.anatron.com.au> <kde706$3t0$1@dont-email.me> <simqs9-ue9.ln1@main.anatron.com.au> |
On 1/19/2013 9:18 AM, Russell Shaw wrote:
> On 20/01/13 00:27, Eric Sosman wrote:
>> [...]
>> Have you ever run into the (in)famous "struct declaration
>> in parameter list" problem (FAQ Question 2.5)? That's very much
>> like what's happening here: Having written a type declaration
>> without a name (tag) or alias (typedef), you have no way to
>> designate that same type again.
>
> Why should it matter that the second struct is "declared" in a separate
> translation unit? To be able to do the assignment, you have to #include
> that second declaration in to the first file anyway.
The point of separate compilation is that the compilations
are, well, separate. The compiler processes one file on Tuesday
and the other on Wednesday, perhaps even on different machines.
The two declarations are not visible to the compiler at the same
time, so the compiler has no way to connect them. The compiler
cannot even tell that the declarations were #include'd from the
same file -- or, quite likely, from distinct files with identical
content (Tuesday's compilation on Machine A, Wednesday's on
Machine B with files copied via FTP, say).
That's why there's a special dispensation for textually
similar type declarations in different translation units: Without
such a rule, separate compilation simply wouldn't work.
Within a single translation unit, though, things are different.
Two "anonymous" type declarations are treated as distinct types,
even if they bear a strong resemblance. Yes, this can lead to a
paradox, where two types in Module X are mutually incompatible,
but are both compatible with a single type in Module Y. Don't
get too hung up over it; just laugh it off and maybe use it as
a trick question to win bets down at the nerd bar.
> It's easy to write a compiler to do that assignment deterministically,
> so why's it not allowed?
I'm not entirely sure what you mean by this -- but if "it's
easy," go ahead and do it. Get the gcc source, modify the compiler
to treat duplicated anonymous declarations the way you want, try it
out on assorted code bases, and see where it leads. If the outcome
is good, your modification can be "prior art" to support a proposal
to the next revision of the Standard.
> p.6.2.7 describes the compatability for structs in separate translation
> units, but says nothing (ie, does not forbid) about assignments in the
> same translation unit.
6.2.7 doesn't allow or forbid any kind of assignment; the
string "assign" does not even appear there.
Assignment is covered in 6.5.16, and in 6.5.16.1p1 (second
bullet) you'll find the requirement that struct assignment must
be between compatible types. *Then* we go back to 6.2.7 to read
the rules on compatibility, and learn that identical anonymous
struct types are compatible only if declared in separate
translation units. Your pair are not in separate translation
units so that language doesn't apply; the structs are therefore
incompatible and do not satisfy the "shall" of 6.5.16.1.
--
Eric Sosman
esosman@comcast-dot-net.invalid
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Struct assignment Russell Shaw <rjshawN_o@s_pam.netspace.net.au> - 2013-01-19 23:09 +1100
Re: Struct assignment Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-01-19 08:27 -0500
Re: Struct assignment Russell Shaw <rjshawN_o@s_pam.netspace.net.au> - 2013-01-20 01:18 +1100
Re: Struct assignment "BartC" <bc@freeuk.com> - 2013-01-19 14:59 +0000
Re: Struct assignment Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-01-19 11:25 -0500
Re: Struct assignment Russell Shaw <rjshawN_o@s_pam.netspace.net.au> - 2013-01-20 12:46 +1100
Re: Struct assignment Bart van Ingen Schenau <bart@ingen.ddns.info.invalid> - 2013-01-20 09:20 +0000
Re: Struct assignment Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-01-20 09:08 -0500
Re: Struct assignment Russell Shaw <rjshawN_o@s_pam.netspace.net.au> - 2013-01-21 12:02 +1100
Re: Struct assignment Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-01-20 22:08 -0500
Re: Struct assignment James Kuyper <jameskuyper@verizon.net> - 2013-01-20 23:21 -0500
Re: Struct assignment James Kuyper <jameskuyper@verizon.net> - 2013-01-21 08:23 -0500
Re: Struct assignment Russell Shaw <rjshawN_o@s_pam.netspace.net.au> - 2013-01-22 13:33 +1100
Re: Struct assignment Russell Shaw <rjshawN_o@s_pam.netspace.net.au> - 2013-01-23 19:53 +1100
Re: Struct assignment Shao Miller <sha0.miller@gmail.com> - 2013-01-19 11:45 -0500
Re: Struct assignment Russell Shaw <rjshawN_o@s_pam.netspace.net.au> - 2013-01-20 13:21 +1100
Re: Struct assignment Shao Miller <sha0.miller@gmail.com> - 2013-01-20 01:06 -0500
Re: Struct assignment Russell Shaw <rjshawN_o@s_pam.netspace.net.au> - 2013-01-20 18:03 +1100
Re: Struct assignment glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-19 19:18 +0000
Re: Struct assignment James Kuyper <jameskuyper@verizon.net> - 2013-01-19 15:22 -0500
Re: Struct assignment Shao Miller <sha0.miller@gmail.com> - 2013-01-19 15:47 -0500
Re: Struct assignment Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-01-19 17:56 -0500
Re: Struct assignment Tim Rentsch <txr@alumni.caltech.edu> - 2013-01-20 12:12 -0800
Re: Struct assignment falk@rahul.net (Edward A. Falk) - 2013-01-19 23:41 +0000
Re: Struct assignment glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-20 01:01 +0000
Re: Struct assignment James Kuyper <jameskuyper@verizon.net> - 2013-01-19 20:53 -0500
Re: Struct assignment Tim Rentsch <txr@alumni.caltech.edu> - 2013-01-20 12:03 -0800
csiph-web