This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: Gcc and the volatile keyword
- From: Sergei Organov <osv at javad dot com>
- To: ecos-discuss at sources dot redhat dot com
- Date: Thu, 16 Feb 2006 12:30:16 +0300
- Subject: [ECOS] Re: Gcc and the volatile keyword
- References: <6.1.0.6.0.20060215141438.01d8e778@66.125.189.29>
Chuck McManis <cmcmanis@mcmanis.com> writes:
[...]
> /* An element in the ring of read descriptors */
> struct vt8325_rdd {
> cyg_unint32 flags;
> cyg_unit32 len;
> cyg_uint8 *buf;
> struct vt8325_rdd *nxt;
> };
>
> And then in the function :
> volatile struct vt8325_rdd *rdes;
>
> if (0 == (rdes->flags & VT8325_RDES_OWNED)) {
> ... not owned ...
>
> }
>
> The question is whether the volatile keyword is transitive to the
> structure elements through a pointer,
Yes, it is. Volatile is OK here though I'm afraid you may have entirely
different problem with portability, -- it's structure fields
alignment. E.g., the offset of 'nxt' field is most probably 12 bytes
from the beginning of the structure, not 9.
Well, I do have a worry about volatile here. I feel I've seen some
version of GCC may re-arrange access to different fields of the volatile
struct, but I'm not sure.
> or if only the pointer to the structure is considered volatile?
No, you don't have volatile pointer, volatile is what it points to. In
case you are curious, to have volatile pointer, you declare it like this:
struct vt8325_rdd * volatile rdes;
and no, you definitely don't need volatile pointer here.
> And if its the latter and I explicity coded it:
>
> /* An element in the ring of read descriptors */
> struct vt8325_rdd {
> volatile cyg_unint32 flags;
> volatile cyg_unit32 len;
> volatile cyg_uint8 *buf;
> volatile struct vt8325_rdd *nxt;
> };
This shouldn't hurt either. One drawback is that it doesn't allow you to
have optimal local non-volatile variables of this type though I doubt it
does matter in this particular case.
Overall, I'd refrain from using structures to describe entities external
to the program whenever possible due to potential alignment problems.
-- Sergei.
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss