Return to the
comp.compilers page.
Search the
comp.compilers archives again.
| From: | David Brown <david.brown@hesbynett.no> |
| Newsgroups: | comp.compilers |
| Date: | Wed, 8 May 2019 10:18:26 +0200 |
| Organization: | A noiseless patient Spider |
| References: | 19-04-021 19-04-023 19-04-037 19-04-039 19-04-042 19-04-044 19-04-047 19-05-004 19-05-006 19-05-016 19-05-020 19-05-024 19-05-025 19-05-028 19-05-032 19-05-039 19-05-047 |
| Injection-Info: | gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="53590"; mail-complaints-to="abuse@iecc.com" |
| Keywords: | C, standards |
| Posted-Date: | 08 May 2019 12:35:14 EDT |
| Content-Language: | en-GB |
On 07/05/2019 15:05, David Brown wrote:
> On 06/05/2019 15:40, Andy Walker wrote:
>> On 06/05/2019 01:15, our esteemed moderator wrote:
>>> [In the struct { int a,b,c,d; } S example it is my understanding that
>>> &S and &S.a
>>> have to be the same,
>>
>> Not "the same", as they have different types; but yes, they must
>> compare equal.
>>
>
> No they don't - not in C. They are incompatible pointers, and comparing
> them is a constraint violation. That means a compiler has to complain
> about trying to evaluate "&S == &S.a".
>
> [My draft of C11 says in section 6.7.2.1: "A pointer to a structure
> object, suitably converted, points to its initial member (or if that
> member is a bit-field, then to the unit in which it resides), and vice
> versa. There may be unnamed padding within a structure object, but not
> at its beginning." -John]
Yes. But in this sample, the pointer was not "suitably converted". You
are allowed to write "(int*) &S == &S.a", and it will always be true.
Return to the
comp.compilers page.
Search the
comp.compilers archives again.