On 05/04/17 15:38 +0000, Bernd Edlinger wrote:
On 04/05/17 17:23, Richard Biener wrote:
On April 5, 2017 4:50:32 PM GMT+02:00, Florian Weimer <fwei...@redhat.com>
wrote:
On 04/05/2017 11:46 AM, Bernd Edlinger wrote:
+@item always_alias
+@cindex @code{always_alias} type attribute
+Same as @code{may_alias}, but additionally applies to instances of
+types with this attribute.
As a GCC user, I have to say that this doesn't really explain what the
attribute does. The C standard does not define what an “instance” of a
type is.
Agreed.
I don't like the name. I'd name it 'typeless_storage' and document that when
storage is accessed with a type with this attribute it it behaves like a
character type with respect to semantics.
you mean you like to name it __attribute__((typeless_storage)) ?
I wanted to say it behaves mostly like __attribute__((may_alias))
except that may_alias only has an effect on pointers and references
but not when accessing an object directly, (I hope you know what
I mean).
And may_alias is not a very helpful name either.
I much prefer Richi's suggestion of typeless_storage.
But I'm not convinced we need the attribute at all. If a struct
containing an array of std::byte or unsigned char has the property
already then that's good. I don't think we need a non-portable way to
make other types behave the same. If you can change the code to use a
new GCC attribute then you can change the code to use an array of
unsigned char, and be portable.
