This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: volatile semantics


On Sat, 2005-07-16 at 19:35 +0100, Nathan Sidwell wrote:
> Daniel Berlin wrote:
> >>> object volatile).
> >>
> >>
> >> I don't understand your point. given
> >>     void Foo (char const * a) { *(char *)a = 5; }
> >> the compiler generates code to store 5 through the pointer 'a'.  It
> >> doesn't turn
> >> this into a call to 'abort', because it thinks you're writing to const
> >> storage.
> > 
> > 
> > Is this *always* the cast, or just in the example above?
> 
> I thought we were discussing the case where there is no static information about
> what the pointer actually points to. I.e. the case of an incoming pointer
> parameter of a function that is not being inlined (or equivalent).

If so, i  have no problem, but then you end up with people claiming we
shouldn't know info we actually do, etc.

> 
> 
> > It appears he was saying that *even if it could determine the static
> > type*, the volatile qualifier on the cast *made the object not that type
> > anymore*. And i'm not sure why such a thing would apply only to
> > volatile, if true.
> 
> I could not determine whether that was the case of Hugh Redelmeier's argument --
> the example is an incomping pointer parameter.

> 
> I agree with you, Daniel, that if the static object can be determined, then its
> type qualifiers win.
> 
> nathan


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]