Re: how to cast away 'volatile'?

[Matthew Woehlke <mw_triad at users dot sourceforge dot net>]

Andrew Haley wrote:
> Matthew Woehlke writes:
> > Andrew Haley wrote:
> > > Matthew Woehlke writes:
> > > > So far no one has successfully answered my original question; how do I 
> > > > suppress these dang warnings? :-)
> > >
> > > I did.  Maybe you didn't see it, or maybe you didn't like the
> > > suggestion.
> >
> > "Didn't see it"? I just re-read your posts; the only thing I see that 
> > might be a suggestion is "don't use volatile". So if there was something 
> > else, I must apologize, because I'm not finding it. :-)
>
> I suggested keeping a non-volatile pointer (to the alloc'd memory) and
> a volatile pointer to the same memory, and using whichever was
> appropriate.  I still think that's a good idea.  The warning from gcc
> *is* correct: you're casting away volatile.  Sure, you might be able
> to find a way to shut up the warning, but is it not surely better to
> fix the code instead?

Hmm... the problem is that this is from an API, the code using the API 
would have to keep track of both. Conversely, since the type is meant to 
be opaque, callers don't need to know that it is volatile. So I can do 
sneaky things like this:

typedef struct { volatile long a; } atom_t;

...whenever it is accesses, m->a is used, which is volatile. But the 
struct as a whole (which is not volatile) can be passed to free(). This 
way the caller is "tricked" into keeping both a volatile and 
non-volatile around at the same time. :-)

See, it took someone to force me to think about a different approach to 
solve this... thanks! :-) (The 'keep both' part was the important part; 
your original suggestion wasn't worded quite the same. This way I'm not 
"casting as needed", which is the part of your original suggestion that 
made me nervous. The actual data is *always* volatile, but it is wrapped 
in something that gcc doesn't complain about when the container is 
passed to free().)

--
Matthew
"unsubscribe me plz!!" -- Newbies