Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| 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> |
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
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