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


Groups > comp.lang.c > #94310

Re: volatile in struct member

From James Kuyper <jameskuyper@verizon.net>
Newsgroups comp.lang.c
Subject Re: volatile in struct member
Date 2016-09-30 12:53 -0400
Organization A noiseless patient Spider
Message-ID <nsm59f$7a3$1@dont-email.me> (permalink)
References <dc811de3-cad5-4f57-b68d-dd8b0252e507@googlegroups.com> <nslpnq$u9r$1@dont-email.me> <a85b1a45-8301-4648-bbc1-6791506aed9c@googlegroups.com>

Show all headers | View raw


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.

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