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.)
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.
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.
(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.)
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".
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!
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
