Re: C strict aliasing rules

[Till Straumann <strauman@slac.stanford.edu>]

> 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 qualiïed 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
>     qualiïed 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,
Just to give you one example:

All records break the rule when they use device support e.g., from 
'softDev'.
These device support modules all declare their DSETs as anonymous structures
which are then accessed from record support as different structures (in the
sense of C99) (e.g., in aiRecord the anonymous DSET is accessed as a 
struct aidset).
They violate the rule because DSET must only be accessed by an lvalue
with a compatible type. 'struct aidset' is not strictly compatible (from 
6.2.7-1)
"Moreover, two structure,
 union, or enumerated types declared in separate translation units are 
compatible if their
 tags and members satisfy the following requirements: If one is 
declared with a tag, the
 other shall be declared with the same tag. If both are complete types, 
then the following
 additional requirements apply: there shall be a one-to-one 
correspondence between their
 members such that each pair of corresponding members are declared with 
compatible
 types, and such that if one member of a corresponding pair is declared 
with a name, the
 other member is declared with the same name. ..."

because

- struct aidset has a tag and the anonymous structure in devAiSoft.c 
has not
- the member names 'dev_report' vs. 'report' differ.

Not that I think any current compiler will use the rule and generate
code that breaks in this case but I make this point just to illustrate that
nobody thought about that rule in the early days and it is very, very hard
to identify violations in hindsight.

Another place where the alias rule is probably violated are network
buffers. These are declared as arrays of characters but accessed
as more complex structures. (The standard seems to only allow the
converse: access a struct as an array of chars but not the other
way round [but gcc seems to treat both cases symmetrically]).

-- Till

PS: CC me on any replies, please - I'm not on this list.
> 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