Re: Uninitialized memory, malloc and unsigned char

On May 30, 7:24 am, Jun Woong <wo...@xxxxxxxxx> wrote:
lawrence.jo...@xxxxxxxxxxx wrote:
Jun Woong <wo...@xxxxxxxxx> wrote:

I'm surprised, however, to see the last sentence quoted above. That
seems to say that an implementation is prohibited from incurring
undefined behavior even when the member of a struct being assigned
has a trap representation and it does the member-to-member
assignment. Is this really intended, or does the sentence in question
have to read as

The value of a structure or union object is not allowed to have a
trap representation unless one of its members has a trap
representation.

It is really intended -- structs and unions do not have trap
representations. See DR #222, which is what motivated that sentence.

Thanks for the reference. It was why I felt unfamiliar with the
wording that it was added by TC2!

I agree that such a wording has to be there given many existing
constructs using partially-initialized structures, even if I tried to
fully initialize them even when only used in part.

Now what I wonder is, if the committee really intended to allow an
erroneous code like

struct {
/* members whose types allow a trap representation */
} foo, bar;

foo = bar;

to be strictly conforming.

I think small touch could improve that new wording to preclude this
anomaly.


I don't think this matters if we accept that unsigned char cannot trap
in any circumstances.

All the standard does is require that structure members be copied by
something analogous to memcpy rather than member assignment.

But it's fairly obvious that it has to work like this anyway.

union u {
double d;
unsigned char c[sizeof(double)];
};

void func(void) {
union u x,y;
memcpy(&y.c, &double_trap_representation, sizeof y.c);
union_assignment_in_different_compilation_unit(&x, &y);
}

union_assignment_in_different_compilation_unit(&x, &y) {
*x = *y;
}

Unless the union is going to be required to carry additional bits
around with it signaling the valid members then I don't think there's
any way the compiler can be aware which member(s) to use to do the
assignment.

Note that my earlier impression of what the standard was saying with
regard to uninitialized bytes is not incompatible with this.

Tim.
.

Relevant Pages

  • Re: Uninitialized memory, malloc and unsigned char
    ... the structure or union object may be a trap representation. ... I think this ensures that the holes between sturct members do not ... affect validity of the struct. ...
    (comp.std.c)
  • Re: Uninitialized memory, malloc and unsigned char
    ... struct s; ... the structure or union object may be a trap representation. ... I think this ensures that the holes between sturct members do not ...
    (comp.std.c)
  • Re: Uninitialized memory, malloc and unsigned char
    ... struct s; ... the structure or union object may be a trap representation. ... I think this ensures that the holes between sturct members do not ...
    (comp.std.c)
  • Re: Uninitialized memory, malloc and unsigned char
    ... undefined behavior even when the member of a struct being assigned ... has a trap representation and it does the member-to-member ... assignment. ...
    (comp.std.c)
  • Re: Structure size directives
    ... When you target a specific architecture, the alignment requirements are know apriori, so system developers do make use of explicit alignment and knows what they are doing. ... struct foo obj; ... offset of 4 bytes, and with the #pragma pack, it would be allocated at ... There are really two different cases here, you talk about the usage of "pack" to minimize padding in a struct, while I talk about the "pack " usage, which specify alignmentof struct members. ...
    (comp.lang.c)