EPICS Home

Experimental Physics and Industrial Control System


 
2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: C strict aliasing rules
From: Andrew Johnson <[email protected]>
To: Eric Norum <[email protected]>
Cc: Core talk list <[email protected]>
Date: Tue, 28 Nov 2006 13:09:34 -0600
Eric Norum wrote:

On Nov 28, 2006, at 9:50 AM, Kay-Uwe Kasemir wrote:

For which we have to know where it all affects us: - register
access, I/O buffer encoding/decoding via mapped structures -
do-it-yourself inheritance from dbCommon to xyzRecord What else?

I think that I/O buffer encoding/decoding via *any* cast, not just
via mapped structures might be at risk.

I'm still not convinced that this is quite as big a problem as Eric does. In his example, the code is breaking this C99 rule:

An object shall have its stored value accessed only by an lvalue
expression that has one of the following types: 74)
- a type compatible with the effective type of the object,
- a qualified version of a type compatible with the effective type of
the object,
- a type that is the signed or unsigned type corresponding to the
effective type of the object,
- a type that is the signed or unsigned type corresponding to a
qualified version of the effective type of the object,
- an aggregate or union type that includes one of the aforementioned
types among its members (including, recursively, a member of a
subaggregate or contained union), or
- a character type.

74) The intent of this list is to specify those circumstances in
which an object may or may not be aliased.

Note that the rule is only talking about accessing the stored value of an object, it says nothing about how you do that, so I think the pointer casting may be a bit of a red herring (it seemed to make no difference in Eric's tests if he passed the value in using a char*, which would make sense given the above rules - he never accessed the value as a char and that's the only other unrelated type the above rules allow).

I don't think the code in Base breaks that rule very often if at all, although it may not be particularly obvious since we do cast pointers to char*, void* or void** and back. However, we never actually use a double* to actually read a value from a long*, and that's where strict aliasing optimization would be entitled to clobber our code. I think our dbCommon* casts for record types all fall into the first option in the rule, so I don't see them as being a problem.

I'm not saying that we have no aliasing problems, but I don't think they'll be as widespread as you might think. For now we should turn on -fno-strict-aliasing on those targets that use gcc 3.x or later, and keep running and improving our test suite with it off to try and detect any aliasing problems that gcc doesn't warn us about.

- Andrew
--
There is considerable overlap between the intelligence of the smartest
bears and the dumbest tourists -- Yosemite National Park Ranger

Replies:
Re: C strict aliasing rules Eric Norum
References:
C strict aliasing rules Eric Norum
Re: C strict aliasing rules Benjamin Franksen
Re: C strict aliasing rules Eric Norum
Re: C strict aliasing rules Benjamin Franksen
Re: C strict aliasing rules Kay-Uwe Kasemir
Re: C strict aliasing rules Marty Kraimer
Re: C strict aliasing rules Eric Norum
Re: C strict aliasing rules Kay-Uwe Kasemir
Re: C strict aliasing rules Eric Norum

Navigate by Date:
Prev: Re: C strict aliasing rules Eric Norum
Next: Re: C strict aliasing rules Eric Norum
Index: 2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: C strict aliasing rules Eric Norum
Next: Re: C strict aliasing rules Eric Norum
Index: 2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024