Hi David,
Am Montag, dem 18.03.2024 um 10:00 +0100 schrieb David Brown:
> Hi,
>
> I would very glad to see this change in the standards.
>
>
> Should "byte type" include all character types (signed, unsigned and
> plain), or should it be restricted to "unsigned char" since that is the
> "byte" type ? (I think allowing all character types makes sense, but
> only unsigned char is guaranteed to be suitable for general object
> backing store.)
At the moment, the special type that can access all others are
all non-atomic character types. So for symmetry reasons, it
seems that this is also what we want for backing store.
I am not sure what you mean by "only unsigned char". Are you talking
about C++? "unsigned char" has no special role in C.
>
> Should it also include "uint8_t" (if it exists) ? "uint8_t" is often an
> alias for "unsigned char", but it could be something different, like an
> alias for __UINT8_TYPE__, or "unsigned int
> __attribute__((mode(QImode)))", which is used in the AVR gcc port.
I think this might be a reason to not include it, as it could
affect aliasing analysis. At least, this would be a different
independent change to consider.
>
> In my line of work - small-systems embedded development - it is common
> to have "home-made" or specialised memory allocation systems rather than
> relying on a generic heap. This is, I think, some of the "existing
> practice" that you are considering here - there is a "backing store" of
> some sort that can be allocated and used as objects of a type other than
> the declared type of the backing store. While a simple unsigned char
> array is a very common kind of backing store, there are others that are
> used, and it would be good to be sure of the correctness guarantees for
> these. Possibilities that I have seen include:
>
> unsigned char heap1[N];
>
> uint8_t heap2[N];
>
> union {
> double dummy_for_alignment;
> char heap[N];
> } heap3;
>
> struct {
> uint32_t capacity;
> uint8_t * p_next_free;
> uint8_t heap[N];
> } heap4;
>
> uint32_t heap5[N];
>
> Apart from this last one, if "uint8_t" is guaranteed to be a "byte
> type", then I believe your wording means that these unions and structs
> would also work as "byte arrays". But it might be useful to add a
> footnote clarifying that.
>
I need to think about this.
> (It is also not uncommon to have the backing space allocated by the
> linker, but then it falls under the existing "no declared type" case.)
Yes, although with the change we would make the "no declared type" also
be byte arrays, so there is then simply no difference anymore.
>
>
> I would not want uint32_t to be considered an "alias anything" type, but
> I have occasionally seen such types used for memory store backings. It
> is perhaps worth considering defining "byte type" as "non-atomic
> character type, [u]int8_t (if they exist), or other
> implementation-defined types".
This could make sense, the question is whether we want to encourage
the use of other types for this use case, as this would then not
be portable.
Are there important reason for not using "unsigned char" ?
>
> Some other compilers might guarantee not to do type-based alias analysis
> and thus view all types as "byte types" in this way. For gcc, there
> could be a kind of reverse "may_alias" type attribute to create such types.
>
>
>
> There are a number of other features that could make allocation
> functions more efficient and safer in use, and which could be ideally be
> standardised in the C standards or at least added as gcc extensions, but
> I think that's more than you are looking for here!
It is possible to submit proposal to WG14.
Martin
>
> David
>
>
>
> On 18/03/2024 08:03, Martin Uecker via Gcc wrote:
> >
> > Hi,
> >
> > can you please take a quick look at this? This is intended to align
> > the C standard with existing practice with respect to aliasing by
> > removing the special rules for "objects with no declared type" and
> > making it fully symmetric and only based on types with non-atomic
> > character types being able to alias everything.
> >
> >
> > Unrelated to this change, I have another question: I wonder if GCC
> > (or any other compiler) actually exploits the " or is copied as an
> > array of byte type, " rule to make assumptions about the effective
> > types of the target array? I know compilers do this work memcpy...
> > Maybe also if a loop is transformed to memcpy?
> >
> > Martin
> >
> >
> > Add the following definition after 3.5, paragraph 2:
> >
> > byte array
> > object having either no declared type or an array of objects declared with
> > a byte type
> >
> > byte type
> > non-atomic character type
> >
> > Modify 6.5,paragraph 6:
> > The effective type of an object that is not a byte array, for an access to
> > its
> > stored value, is the declared type of the object.97) If a value is
> > stored into a byte array through an lvalue having a byte 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.
> > If a value is copied into a byte array using memcpy or memmove, or is
> > copied as an array of byte type, then the effective type of the
> > modified object for that access and for subsequent accesses that do not
> > modify the value is the effective type of the object from which the
> > value is copied, if it has one. For all other accesses to a byte array,
> > the effective type of the object is simply the type of the lvalue used
> > for the access.
> >
> > https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3230.pdf
> >
> >
> >
>
--
Univ.-Prof. Dr. rer. nat. Martin Uecker
Graz University of Technology
Institute of Biomedical Imaging
