bearophile wrote:
The first of them is fixed in C99 with the 'restrict' keyword. I
guess the D compiler has to assume all pointers can be an alias to
each other (but I don't remember if the D docs say this explicitely
somewhere) because I think D prefers to not give keywords that the
compiler itself can't then test and make sure they are correct.
'restrict' is not at all about eliminating undefined behavior. It is
about providing more information to the optimizer so better code can be
generated. If restrict is used incorrectly, however, undefined behavior
can result. D doesn't have this problem because D doesn't have the
restrict qualifier.
The second of them is relative to code like:
enum SI { short s; int i; } void main() { SI e; e.i = 1_000_000; int
foo = e.s; }
I think that according the C standard this code (the contents of foo)
is undefined. Is D going to define this, or is it going to leave this
undefined as in C? (Leaving it undefined can speed up a little the D
code, but making it defined can make D more flexible, for example you
can use an enum to split an int in two shorts in a reliable way).
Note: here I am talking about D unsafe modules, because I think safe
D modules can't use enums. So I am talking about the possibility of
removing some undefined behaviours from unsafe D modules.
D leaves byte ordering (endianness) implementation defined. I see no way
to do otherwise without incurring severe performance penalties.
Probably the C standard leaves other things undefined. Some of them
can cause bugs in unsafe D code.
Yes, endianness issues can cause bugs.
