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

Groups > comp.lang.c > #94280 > unrolled thread

volatile in struct member

Back to article view | Back to comp.lang.c

Contents

  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

#94280 — volatile in struct member

Can this make sense?

struct 
{
  volatile int i;
};

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
 
}

by the way, the register keyword has been deprecated in C++17 (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4340)

[toc] | [next] | [standalone]

#94284

On Friday, September 30, 2016 at 12:54:19 PM UTC+1, Thiago Adams wrote:
> Can this make sense?
> 
> struct 
> {
>   volatile int i;
> };
> 
It makes perfect sense. The member must never be stored in a register but read from memory
and written back at every operation.

I think it is also allowed.

[toc] | [prev] | [next] | [standalone]

#94291

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> On Friday, September 30, 2016 at 12:54:19 PM UTC+1, Thiago Adams wrote:
>> Can this make sense?
>> 
>> struct 
>> {
>>   volatile int i;
>> };
>> 
> It makes perfect sense. The member must never be stored in a register
> but read from memory and written back at every operation.

Though (probably not intentionally) the OP has made a struct that has no
tag and is not part of a declaration of some objects, so there can never
be a member to read and written from memory!

But I suspect the question is more about the placement of the keyword.
I'd put the volatile on the object declaration:

  struct small { int i; };
  volatile struct small sm;

So I think what's being asked is if there is any reason ever to put in
in the struct rather than on the declared object.  A more detailed
example might have used a mixed structure like this:

 struct mixed {
     int i;
     volatile int v;
     char bytes[8];
 };

where you can't get the same effect by volatile qualifying an object of
the this type.

> I think it is also allowed.

In general, yes, though the exact example given is not useful.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#94335

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> But I suspect the question is more about the placement of the keyword.
> I'd put the volatile on the object declaration:
>
>   struct small { int i; };
>   volatile struct small sm;

But one could easily imagine a struct like

struct register
{
   volatile int * address;
   int last_written_value;
}

void write_reg(struct register*reg,int val)
{
  *reg->address = val;
  last_written_value = val;
}

int read_reg(struct register*reg,int val)
{
  return reg->last_written_value;
}

I wouldn't need to have the cached value marked as volatile (though in a
trivial example like this it would make little difference to performance).

I've programmed FPGAs with "write only" registers like this.

[toc] | [prev] | [next] | [standalone]

#94338

Gareth Owen <gwowen@gmail.com> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> But I suspect the question is more about the placement of the keyword.
>> I'd put the volatile on the object declaration:
>>
>>   struct small { int i; };
>>   volatile struct small sm;
>
> But one could easily imagine a struct like
>
> struct register
> {
>    volatile int * address;
>    int last_written_value;
> }

I don't think anyone has been questioning the validity of pointing to
volatile data.

> void write_reg(struct register*reg,int val)
> {
>   *reg->address = val;
>   last_written_value = val;
> }
>
> int read_reg(struct register*reg,int val)
> {
>   return reg->last_written_value;
> }
>
> I wouldn't need to have the cached value marked as volatile (though in a
> trivial example like this it would make little difference to performance).
>
> I've programmed FPGAs with "write only" registers like this.

I think I'm missing your point.  The fact that you are writing
hypothetically ("I wouldn't need") makes it particularly tricky (for me,
at least).

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#94288

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

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#94294

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.

[toc] | [prev] | [next] | [standalone]

#94299

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.

> 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.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#94305

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.
> 

[toc] | [prev] | [next] | [standalone]

#94632

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> 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
> while 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

This explanation isn't exactly right.  Some qualifiers go with the
declarator, but some go with the type.  For example,

    int const i, j;

results in both i and j being of type 'const int'.  Here the 'const'
qualifier goes with the type, not with the declarator.

[toc] | [prev] | [next] | [standalone]

#94289

On 30/09/16 13:52, Thiago Adams wrote:
> Can this make sense?
> 
> struct 
> {
>   volatile int i;
> };
> 
> 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
>  
> }
> 
> by the way, the register keyword has been deprecated in C++17
> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4340)
> 

volatile on struct members is perfectly acceptable, and compilers will
treat an access to a volatile member just like other volatile accesses.
 It is the kind of thing you might well see in embedded systems for
mapping hardware registers or for data that is accessible from
interrupts and the main loop code.  Often the whole struct is volatile,
but occasionally it's just particular members.

Extra information for static analysis programs is usually put in
specially formatted comments for stand-alone programs, or appropriate
compiler extensions (such as #pragma's or __attribute__'s) when it is
part of the compiler.

[toc] | [prev] | [next] | [standalone]

#94292

On Friday, September 30, 2016 at 10:36:15 AM UTC-3, David Brown wrote:
...
> volatile on struct members is perfectly acceptable, and compilers will
> treat an access to a volatile member just like other volatile accesses.
>  It is the kind of thing you might well see in embedded systems for
> mapping hardware registers or for data that is accessible from
> interrupts and the main loop code.  Often the whole struct is volatile,
> but occasionally it's just particular members.
> 
> Extra information for static analysis programs is usually put in
> specially formatted comments for stand-alone programs, or appropriate
> compiler extensions (such as #pragma's or __attribute__'s) when it is
> part of the compiler.

Thanks all. I was just curious.

In this case I can use a macro.

//suport header
#ifndef STATIC_ANALYSER
#define myqualifier
#else
//"build-in"
#end

If I use #pragma to give information for the static analysis then the compiler
complains "warning I don't know this"

[toc] | [prev] | [next] | [standalone]

#94310

On 09/30/2016 09:47 AM, Thiago Adams wrote:
> On Friday, September 30, 2016 at 10:36:15 AM UTC-3, David Brown wrote:
> ...
>> volatile on struct members is perfectly acceptable, and compilers will
>> treat an access to a volatile member just like other volatile accesses.
>>  It is the kind of thing you might well see in embedded systems for
>> mapping hardware registers or for data that is accessible from
>> interrupts and the main loop code.  Often the whole struct is volatile,
>> but occasionally it's just particular members.
>>
>> Extra information for static analysis programs is usually put in
>> specially formatted comments for stand-alone programs, or appropriate
>> compiler extensions (such as #pragma's or __attribute__'s) when it is
>> part of the compiler.
> 
> Thanks all. I was just curious.
> 
> In this case I can use a macro.
> 
> //suport header
> #ifndef STATIC_ANALYSER
> #define myqualifier
> #else
> //"build-in"
> #end
> 
> If I use #pragma to give information for the static analysis then the compiler
> complains "warning I don't know this"

Well, of course. The #pragma must be known by to the compiler that
performs the static analysis. Use the #pragma with any other compiler
and it's effectively just a different kind of comment.

[toc] | [prev] | [next] | [standalone]

#94312

On Friday, September 30, 2016 at 11:53:24 AM UTC-5, James Kuyper wrote:
> Well, of course. The #pragma must be known by to the compiler that
> performs the static analysis. Use the #pragma with any other compiler
> and it's effectively just a different kind of comment.

The Standard imposes no requirements with regard to the behavior of any
program which contains a #pragma directive whose meaning is not explicitly
specified.  It would have been helpful to define "ownership" of certain
pragma names, such that every compiler than encountered a line starting with
e.g. "#pragma ACME" would be required to either process the line in the
fashion defined by Acme Compiler Corporation or else ignore the line
altogether, but the Standard is silent on such things.

[toc] | [prev] | [next] | [standalone]

#94332

supercat@casperkitty.com wrote:

> On Friday, September 30, 2016 at 11:53:24 AM UTC-5, James Kuyper wrote:
> > Well, of course. The #pragma must be known by to the compiler that
> > performs the static analysis. Use the #pragma with any other compiler
> > and it's effectively just a different kind of comment.
> 
> The Standard imposes no requirements with regard to the behavior of any
> program which contains a #pragma directive whose meaning is not explicitly
> specified.  It would have been helpful to define "ownership" of certain
> pragma names, such that every compiler than encountered a line starting with
> e.g. "#pragma ACME" would be required to either process the line in the
> fashion defined by Acme Compiler Corporation or else ignore the line
> altogether, but the Standard is silent on such things.

Helpful, and entirely impossible.

Richard

[toc] | [prev] | [next] | [standalone]

#94340

On Friday, September 30, 2016 at 3:57:54 PM UTC-5, Richard Bos wrote:
> supercat wrote:

> > The Standard imposes no requirements with regard to the behavior of any
> > program which contains a #pragma directive whose meaning is not explicitly
> > specified.  It would have been helpful to define "ownership" of certain
> > pragma names, such that every compiler than encountered a line starting with
> > e.g. "#pragma ACME" would be required to either process the line in the
> > fashion defined by Acme Compiler Corporation or else ignore the line
> > altogether, but the Standard is silent on such things.
> 
> Helpful, and entirely impossible.

The authors of the Standard may not have wanted to involve themselves
with disputes about ownership, but I see no reason it would not have
been possible to recommend that compiler vendors who want to add new
features should follow certain naming and syntactic conventions when
practical.  If certain conventions would be impractical for 5% of 
implementations, those implementations would be free to do something
else, but that's no reason why the 95% of implementations that could
follow a consistent convention shouldn't do so.

[toc] | [prev] | [next] | [standalone]

#94313

On Friday, September 30, 2016 at 1:53:24 PM UTC-3, 
..
>other compiler
> and it's effectively just a different kind of comment.

comment + warning:

warning : unknown pragma ignored [-Wunknown-pragmas]

I don't know if its worth to turn off.

[toc] | [prev] | [next] | [standalone]

#94334

On Friday, September 30, 2016 at 1:22:10 PM UTC-4, Thiago Adams wrote:
> On Friday, September 30, 2016 at 1:53:24 PM UTC-3, 
> ..
> >other compiler
> > and it's effectively just a different kind of comment.
> 
> comment + warning:
> 
> warning : unknown pragma ignored [-Wunknown-pragmas]
> 
> I don't know if its worth to turn off.

The standard mandates diagnostic messages for any syntax errors, constraint violations, and a few other things. This is not one of the mandatory diagnostics. In fact, the standard says "Any such pragma that is not recognized by the implementation is ignored." (6.10.6p1)
Compilers are free to generate warnings for any reason they wish; they could warn you, for instance, about using sexist variable names. In particular, if you used a comment with a specific format to communicate with a static analysis program, a compiler is perfectly free to issue a warning about that comment. As far as the standard is concerned, the fact that this #pragma resulted in a warning message is not a distinction between using a #pragma for this purpose and using a comment for this purpose.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web