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
