On 04/06/17 19:47, Florian Weimer wrote: > On 04/06/2017 07:39 PM, Bernd Edlinger wrote: >> On 04/06/17 16:17, Florian Weimer wrote: >>>> Here is what I want to write in the doc: >>>> >>>> @item typeless_storage >>>> @cindex @code{typeless_storage} type attribute >>>> A type declared with this attribute behaves like a character type >>>> with respect to aliasing semantics. >>>> This is attribute is similar to the @code{may_alias} attribute, >>>> except that it is not restricted to pointers. >>> >>> As Jakub pointed out, this is not what we need here. An object of type >>> char does *not* have untyped storage. Accessing it as a different type >>> is still undefined. >>> >> >> but, do you agree that this is valid in C11? >> >> typedef char char_a[4]; >> >> int >> main (void) >> { >> char_a a = {1,2,3,4}; >> short *b = (short *) &a; >> >> b[1] = 0; >> >> if (a[0] == 1 && a[1] == 2 && a[2] == 3 && a[3] == 4) >> abort(); >> >> exit(0); >> } >> >> >> all I want to do is replace "char" with a different type. > > Thanks a lot for posting a concrete example. > > The effective type of a[2] and [3] is char. The character type wildcard > in 6.5(7) only applies to the type of the lvalue expression ysed for the > access, not the effective type of the object being accessed. The type > of the LHS of the assignment expression is short. So the access is > undefined. >
exactly *that* is what I want to make valid with that attribute, which would be also useful in C and kernel code, IMHO. But isn't the effective type changed by the assignment b[1] = 0; as described in 6.5(6): "If a value is stored into an object having no declared type through an lvalue having a type that is not a character type, then the type of the lvalue becomes the effective type of the object for that access and for subsequent accesses that do not modify the stored value." Bernd.