Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Default values in #define Date: Mon, 22 Aug 2016 15:47:12 -0700 Organization: None to speak of Lines: 63 Message-ID: References: <87twegmnvj.fsf@bsb.me.uk> <87vaystxvp.fsf@bsb.me.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="945944de09706c9b4e29b53c9d2efdc2"; logging-data="8665"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+XL84C0o7mreIhp3KucEY/" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:1agzgFRCHJVGjEQnxjse46ULK4E= sha1:6/Bxvy4cCdoHqVqi5qTYVNerZJA= Xref: csiph.com comp.lang.c:92606 supercat@casperkitty.com writes: > On Monday, August 22, 2016 at 2:19:32 PM UTC-5, Ben Bacarisse wrote: >> I see a problem even without the array. At first glance it looks like a >> bug. Have you communicated with the clang people to see if they think >> it's a bug? My test case was: >> >> #include >> #include >> >> union U {long long l; int64_t ll;}; >> >> long long f(union U *p1, union U *p2) >> { >> p2->l = 42; >> p1->ll = 0; >> return p2->l; >> } >> >> int main(void) >> { >> union U u; >> printf("%lld\n", f(&u, &u)); >> } >> >> prints 42 with clang -std=c11 -pedantic -O2 (version 3.6.2-1). Is this >> what you mean or are you describing something else? > > That seems like the issue, though I'd noticed the issue first when testing > with two arrays (which used to be an accepted way of handling cases where > data will sometimes be read with one sized of chunk and written as another). > I hadn't thought clang would go so far as to ignore the possibility of > aliasing with directly-accessed lvalue members. > > The problem, of course, is that while the authors of the Standard have > sought to avoid defining behaviors that might not be meaningful on > absolutely all platforms, modern compiler writers treat the Standard as > passing judgement on whether quality implementations should support > behaviors on platforms where they are meaningful. The problem, of course, is that Clang apparently has a bug. The C standard has a footnote in section 6.5.2.3: If the member used to read the contents of a union object is not the same as the member last used to store a value in the object, the appropriate part of the object representation of the value is reinterpreted as an object representation in the new type as described in 6.2.6 (a process sometimes called "type punning"). This might be a trap representation. I can confirm that the bug occurs with clang 3.8.1 on x86-64 (with -O2, but not with -O1). int64_t is defined as long. If I change long long to long in the program (they have the same size and representation), the problem goes away. Not everything is about the vast conspiracy to produce deliberately useless compilers. -- Keith Thompson (The_Other_Keith) kst-u@mib.org Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"