Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: volatile in struct member |
| Date | 2016-09-30 16:22 +0200 |
| Organization | A noiseless patient Spider |
| Message-ID | <nslsfh$8oe$1@dont-email.me> (permalink) |
| References | <dc811de3-cad5-4f57-b68d-dd8b0252e507@googlegroups.com> <87vaxd8qie.fsf@bsb.me.uk> |
On 30/09/16 15:29, Ben Bacarisse wrote:
> Thiago Adams <thiago.adams@gmail.com> writes:
>
>> Can this make sense?
>>
>> struct
>> {
>> volatile int i;
>> };
>
> People sometimes use volatile to alter the way the optimiser works, so
> whilst that may not "make sense" in any portable way, I'd not want to
> rule it out.
>
>> Why this question?
>> I was just trying to find some qualifier to hijack and put other
>> concept on it to use in static analysis if the generated code isn't
>> affected.
>>
>> For curiosity, I tried:
>>
>> struct
>> {
>> register int i1; //error
>> auto int i2; //error
>> restrict i3; //error
>>
>> }
>
> register and auto are storage class specifiers like static. volatile is
> a type qualifier (like const and restrict). The difference is that type
> qualifiers go in the declarator and can be mixed in with *s and []s and
> so on:
>
> register auto long long *const p;
> |------------| |-------| |------|
> storage class type declarator
>
I would say that the key difference is that storage class specifiers
affect the placement, lifetime, linkage and scope of the object, while
the qualifiers affect how the object is accessed. Thus it can make
sense to access different parts of a struct in different ways (const,
volatile), but it does not make sense to have different parts of the
struct have different lifetimes or be in different places.
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
volatile in struct member Thiago Adams <thiago.adams@gmail.com> - 2016-09-30 04:52 -0700
Re: volatile in struct member Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-30 05:50 -0700
Re: volatile in struct member Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-30 14:42 +0100
Re: volatile in struct member Gareth Owen <gwowen@gmail.com> - 2016-09-30 22:09 +0100
Re: volatile in struct member Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-30 22:24 +0100
Re: volatile in struct member Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-30 14:29 +0100
Re: volatile in struct member David Brown <david.brown@hesbynett.no> - 2016-09-30 16:22 +0200
Re: volatile in struct member Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-30 15:51 +0100
Re: volatile in struct member David Brown <david.brown@hesbynett.no> - 2016-09-30 17:07 +0200
Re: volatile in struct member Tim Rentsch <txr@alumni.caltech.edu> - 2016-10-08 15:48 -0700
Re: volatile in struct member David Brown <david.brown@hesbynett.no> - 2016-09-30 15:36 +0200
Re: volatile in struct member Thiago Adams <thiago.adams@gmail.com> - 2016-09-30 06:47 -0700
Re: volatile in struct member James Kuyper <jameskuyper@verizon.net> - 2016-09-30 12:53 -0400
Re: volatile in struct member supercat@casperkitty.com - 2016-09-30 10:18 -0700
Re: volatile in struct member raltbos@xs4all.nl (Richard Bos) - 2016-09-30 20:57 +0000
Re: volatile in struct member supercat@casperkitty.com - 2016-09-30 14:46 -0700
Re: volatile in struct member Thiago Adams <thiago.adams@gmail.com> - 2016-09-30 10:22 -0700
Re: volatile in struct member jameskuyper@verizon.net - 2016-09-30 14:08 -0700
csiph-web