Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #94305

Re: volatile in struct member

Show all headers | View raw

On 30/09/16 16:51, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
> 
>> 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.
> 
> That's a neat summary though it contains the name/object confusion that
> I so dislike!  I'd say
> 
> | The key difference is that storage class specifiers affect the
> | placement and lifetime of the object as well the linkage and scope of
> | the name.  The qualifiers affect how the object is accessed.
> 

Fair enough.

Another distinction is that you can change the qualifiers via pointer
casts or assigning to pointer types with different qualifiers, but you
cannot change the storage class in this way.  (You can use pointers to
get a new name for the object with different scope, which I suppose is
why you want to make the distinction that it is the name that has scope,
not the object.)

So given:

	int x;

You can write:

	*((volatile int *) &x) = 123;	// Force volatile write

(Accesses through pointers with different qualifiers may or may not be
allowed, depending on the original definition of the object.  And
volatile accesses are implementation-dependent anyway.  But forcing a
volatile access like this should work "as expected" on most compilers.)

But you can't write:

	*((static int *) &x) = 123;	// Make x static


And the "restrict" and "_Atomic" qualifiers are a bit more complicated.
 "restrict" does not affect how the qualified pointer itself is
accessed, but it can affect how objects are accessed via that pointer.
And I /think/ that "_Atomic" can change more than just the way an object
is accessed - is it required that an "_Atomic T" has the same size and
layout as a plain "T" ?


>> 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.
> 
> Yes, that's what I was rather tangentially getting at by pointing out
> the syntactic difference.  C embodies this distinction in its syntax by
> not permitting storage class specifiers in struct declarations.
> 

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

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