Re: Volatile qualification on pointer and data

[David Brown <david dot brown at hesbynett dot no>]

On 25/09/11 17:15, Dave Korn wrote:
> On 25/09/2011 13:56, David Brown wrote:
>
> > There is a big difference between defining an object as "const", and
> > merely declaring it as const or accessing it as const.  When you access
> > it as const, you are saying "/I/ won't change the object with this
> > access".  When you declare an object as const (such as an extern
> > object), you are saying "/I/ won't change this object".  When you
> > /define/ an object as const, as you do with a "static const", you are
> > saying "this object is constant.  It will never change value - you (the
> > toolchain) can safely place it in read-only memory that cannot ever
> > change value".
> >
> > And then you make it volatile, telling the compiler "this object might
> > change unexpectedly, or use values written to it unexpectedly".
> >
> > If someone could explain to me how this could have real-world usage, I
> > think it would be easier for me (and others) to be sure of what it
> > really means.
>
>    Just because it's static doesn't mean the address can't escape:
>
> /* May read or write to dest, according to direction flag.  */
> extern void start_dma_xfer (void *dest, unsigned int size, bool direction,
>                              uint64_t bus_addr);
>
> /* We don't want to change this ourselves, and nor do we want the symbol
>     to be externally visible.  */
> static const volatile char *dma_buffer[BUFFERSIZE];
>
> [ ... later, in a function ... ]
>
>    start_dma_transfer (&dma_buffer[0], size, DIRECTION_DMA_TO_MEMORY, devaddr);
>
>
>    A bit contrived perhaps, but start_dma_transfer (or some similar function)
> might be part of the OS or written in assembly and so necessarily C-type-safe.
>
>      cheers,
>        DaveK

I can see that as a possibility, though to me it reads as bad style. 
I'm aware that taking the address of a static object can let it 
"escape", and mentioned that possibility in other posts - it will 
certainly force the object to be created in memory.  However, I just 
don't see why a buffer like this would be defined "const" - it's not 
constant, so what are you trying to achieve by saying "const"?

To answer that, you have to first say /why/ anyone would use the "const" 
qualifier in the first place.  There are five reasons I can think of. 
First, you have compatibility with other code and types.  Then you have 
error-checking - if you know you will not change an object, you make it 
"const" to let the compiler check that you haven't changed it by 
mistake.  Then there is optimisation - by telling the compiler that the 
object won't change value, you let it generate better code (such as 
using "static const" instead of old-fashioned "#define" or enum 
constants).  Next, you define objects as "const" to let the toolchain 
place the object in read-only memory - this is very important for small 
embedded systems running from flash memory.  Finally, you use "const" as 
documentation - you use it when it makes it clearer what the code is 
doing, why it is doing it, or how it is doing it.

So what advantages would there be in declaring a volatile buffer like 
this to be "const"?  At best, you are helping the compiler check that 
you don't accidentally write to it in your own code.  It is dangerous 
regarding optimisation - you definitely don't want the compiler to 
optimise the buffer, yet this whole discussion started because some 
compilers /do/ optimise such code (rightly or wrongly).  You don't want 
the toolchain to put it read-only memory (as noted by another poster, 
doing so would be against the standards - but toolchain writers are not 
infallible, and weird corner-cases like this are where mistakes are less 
likely to be spotted and fixed).  So does the "const" make the program 
clearer to the code writer, and other readers?  I would say it has the 
opposite effect, and leaves a reader wondering what it is supposed to 
mean - the buffer is clearly not meant to be constant, so why is it 
declared "const"?

When I write code, I almost always define objects as "const" when 
possible.  But in this case there would be no doubt in my mind - that 
buffer is /not/ constant, and should not be defined as "const" even if 
it happened to compile and run correctly.

I am aware that this is a stylistic choice.  But I don't see it as good 
programming to push boundaries with "risky" code that might or might not 
work depending on how the compiler writers interpreted the standards - 
especially when it makes the code less clear to human readers.