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, 29 Aug 2016 16:35:28 -0700 Organization: None to speak of Lines: 41 Message-ID: References: <87vaystxvp.fsf@bsb.me.uk> <1d377167-a33a-402e-89ee-d3efa06d95ab@googlegroups.com> <87twebuwwn.fsf@gmail.com> <36a5bcc3-9e30-468c-a3e1-4b9c9788d395@googlegroups.com> <1Kgvz.279$6d.174@fx26.iad> <8277ffd2-121d-4f3a-9bb0-ad3068696415@googlegroups.com> <502669cd-f0fc-4b99-8c8a-0d806c8b5f20@googlegroups.com> <566c947b-91d6-43c1-86aa-772f6cf21e35@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="945944de09706c9b4e29b53c9d2efdc2"; logging-data="26436"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/vTzapqDwFwytkE12GYJ0L" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:9wbriCK6jYpfJkfPXhSox+Zhyws= sha1:4GGESHsjF/BYl8ywf098gUSWFls= Xref: csiph.com comp.lang.c:92912 David Brown writes: > On 29/08/16 18:28, Keith Thompson wrote: >> David Brown writes: >> [...] >>> The C standard is weak on this area - "What constitutes an access to an >>> object that has volatile-qualified type" is implementation defined >>> behaviour. So I think your answer here is that it depends on the compiler. >> [...] >> >> That's not what the standard says. >> >> N1570 6.7.3p7: >> >> What constitutes an access to an object that has volatile-qualified >> type is implementation-defined. >> >> It's the question of whether a given operation is an access to a >> volatile object that's implementation-defined, not the behavior. > > That is really the question. When you make a pointer-to-volatile > using a cast, and access that, is it a volatile access or not? I > /think/ the standard says the answer is implementation-defined - but I > also think that compilers would treat all accesses via pointers as > volatile accesses. My point is that you incorrectly introduce the phrase "implementation defined behaviour". It's not the *behavior* that's implementation-defined, it's the determination of what constitutes an access. Once that's determined, the behavior might be either well defined, implementation-defined, unspecified, or undefined, depending on the specific code. One example of how this is defined is here (for gcc): https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/Qualifiers-implementation.html -- 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"