It is unspecified behavior in C++ to access any member of a union other than the one that was used last to store a value in it.

Is that the case with D as well?

Ali

Ali Çehreli:
> It is unspecified behavior in C++ to access any member of a union other
> than the one that was used last to store a value in it.
> Is that the case with D as well?

I have recently asked Walter about this, my purpose was to remove some undefined situations from D, but after a long discussion there was no clear answer, his answer to solve this problem was to say that SafeD modules can't use unions. Currently there is no official spec on this for unsafe D modules. You have to assume the worst (that is as in C, that assumes the optimization stages of the compiler can optimize away the last store into the union, so you can reliably read what can be the CPU registers only if you use the same type used last time), but I'd like some official way to do this, some way that forces the compiler to read and save the value (something like a volatile for unions, maybe). If you want, you can try asking again to Walter in the main group. (There are several other undecided things like this, like something related to pointer aliasing, etc).

Bye,
bearophile

Ali Çehreli wrote:
> It is unspecified behavior in C++ to access any member of a union other than the one that was used last to store a value in it.
> 
> Is that the case with D as well?
> 
> Ali

yes, union in D is the same as C/C++

- --
My enormous talent is exceeded only by my outrageous laziness.
http://www.ssTk.co.uk

bearophile wrote:
>
> are several other undecided things like this,

It's not undecided. It's very clear that a union is exactly equivalent to it's C/C++ counter for the specific purposes of C/C++ interop and other low level features like painting struct/unions over hardware addresses.

Just cause you don't like the feature doesn't mean it's unclear, buggy or otherwise pointless.

- --
My enormous talent is exceeded only by my outrageous laziness.
http://www.ssTk.co.uk

div0:
> Just cause you don't like the feature doesn't mean it's unclear, buggy or otherwise pointless.

In this discussion I was talking about two different things:

1) In that answer of mine with the word "undecided" I meant that there are D parts where D specs don't state how a correct D implementation has to behave. For example, how can you be sure that D unions follow the C99 specs?

2) Even if D officially adopts part of C99 specs for some D features, like unions, there can be ways for D to improve its situation compared to C99 (and keep backwards compatibility with C99). For example in D it can be added a syntax/way to more safely perform some unsafe idioms sometimes used in C, like using unions to cast types statically, or to avoid the need of things like the "-fno-strict-aliasing" switch of GCC, etc.

Bye,
bearophile