6

I'm trying to understand the implications of the following statement in the C99 standard (C99; ISO/IEC 9899:1999 6.5/7)

An object shall have its stored value accessed only by an lvalue expression that has one of the following types 73) or 88):

  • (other statements unrelated to question omitted)

  • an aggregate or union type that includes one of the aforementioned types among its members (including, recursively, a member of a subaggregate or contained union)

Consider the following:

typedef struct MyComplex {
    float real;
    float imag;
} MyComplex;

MyComplex *carray = malloc(sizeof(*carray) * 10);
float *as_floats = (float *)carray;

Is this legal since the MyComplex structure contains a compatible float type for the as_floats pointer?

What about the other way around? i.e:

float *farray = malloc(sizeof(*farray) * 10);
MyComplex *as_complex = (MyComplex *)farray;

In both cases, ultimately, everything we're dealing with here is a float, so maybe it's ok? I'm just not sure.

I ask, because I'm dealing with a legacy code base that does this kind of stuff all over the place and so far, everything seems fine. But I feel like we're playing with fire here. Trying to figure out if I need to disable strict aliasing on the compiler command line or not.

mshildt
  • 8,782
  • 3
  • 34
  • 41
  • Should `MyComplex *carray = malloc(sizeof(*carray) * 10);` be `MyComplex *carray = malloc(sizeof(MyComplex) * 10);` ? – ryyker Feb 10 '15 at 14:48
  • No, it's equivalent, except it won't break if the type of `carray` ever changed. – mshildt Feb 10 '15 at 14:49
  • 2
    Related to [Aliasing Arrays through structs](http://stackoverflow.com/q/27908626/1708801) – Shafik Yaghmour Feb 10 '15 at 14:55
  • i don't think things always go so ideally. in fact, it's good for implementation to add padding if necessary, so both way could lead to junk data to be read/written. – Jason Hu Feb 10 '15 at 15:30

3 Answers3

3

Note 13 in 6.7.2.1 of (I believe) all versions of the standard condones case #1 explicitly. You'll rarely get a clearer answer! My emphasis

Within a structure object, the non-bit-field members and the units in which bit-fields reside have addresses that increase in the order in which they are declared. A pointer to a structure object, suitably converted, points to its initial member (or if that member is a bit-field, then to the unit in which it resides), and vice versa. There may be unnamed padding within a structure object, but not at its beginning.

http://port70.net/~nsz/c/c99/n1256.html#6.7.2.1

YES! You can cast a structure to access its first member directly! Why anyone thinks that's better than &(carray->real) isn't clear. But it's definitely legit.

As another commenter pointed out I discussed case #2 in a previous question.

Aliasing Arrays through structs

It appears in conclusion that case #2 is an OK way to access the member real. Also iff the structure has no internal padding (platform dependent) you could even access the second member of the array through imag.

I say platform dependent but other investigations have offered no known platform where such a structure would include padding.

Community
  • 1
  • 1
Persixty
  • 8,165
  • 2
  • 13
  • 35
  • 1
    Very informative, thanks! Hadn't considered the case where the struct could contain padding! – mshildt Feb 10 '15 at 15:48
  • @epicbrew There is (to my knowledge) no known platform where your structure will contain padding! I'd love to hear of one. No one has ever obliged. So for practical purposes it's a non-issue - in your very narrow case. That's because all the members of your structure are the same type. – Persixty Feb 10 '15 at 16:24
  • yes agreed, but still good to know about the potential pitfall for the more general case. :-) – mshildt Feb 10 '15 at 16:26
1

I've tried to reproduce some problems with using this casting approach. One problem is when struct uses bit fields and another - when there is compiler directive which forces struct members to be aligned to some size:

// issue 1 : problem with bitFields
typedef struct MyComplex_1 {
    unsigned int real : 1;
    unsigned int imag : 2;
} MyComplex_1;

// issue 2 : problem with members forced alignment
typedef struct MyComplex_2 {
    unsigned int real;
    unsigned int imag;
} __attribute__ ((aligned (64))) MyComplex_2; // GCC compiler directive

int main()
{
    MyComplex_1 arr_1[] = {{1, 2}, {1, 2}};
    MyComplex_2 arr_2[] = {{1, 2}, {1, 2}};

    int i;

    // for bitfield issue
    for (i=0; i<2; i++)
        printf("struct (%d,%d)\n", arr_1[i].real, arr_1[i].imag);

    for (i=0; i<4; i++)
        printf("var (%d)\n", ((unsigned int*)arr_1)[i]);

    // for struct member forced alignement issue
    for (i=0; i<2; i++)
        printf("struct (%d,%d)\n", arr_2[i].real, arr_2[i].imag);

    for (i=0; i<4; i++)
        printf("var (%d)\n", ((unsigned int*)arr_2)[i]);

    return 0;
}

There may be more problems, but in my opinion this thing is risky.

Agnius Vasiliauskas
  • 10,935
  • 5
  • 50
  • 70
  • Thanks for the examples. Agree that this sort of casting is not ideal. – mshildt Feb 10 '15 at 15:40
  • No problem. C is double-edge sword, it's good that you can make every cast at hand and get good performance, but in contrary - universal casting can be a trouble if used too extensively (see joke in my profile :-) ). – Agnius Vasiliauskas Feb 10 '15 at 15:43
  • @AgniusVasiliauskas: Classic C made you bring your own safety gear and would let you stub your toe if it isn't 100% effective. New improved hyper-modern C recognizes the uselessness of any safety gear that would merely reduce a fatal injury to a stubbed toe, rather than preventing all injury, and will make code more efficient by eliminating such useless safety gear altogether. – supercat Jun 22 '15 at 23:30
0

I agree that you're playing with fire, but not because of the section of the standard you cite.

Any object, including objects that are components of an object of aggregate type (array or struct), is characterized by an address and a type. With the declarations given, consider accesses of these forms (for 0 <= n < 10):

/* 1 */
carray[n].real

/* 2 */
asfloats[n * 2]

The standard says that both of the above forms are allowed ways to access a float object, but it says nothing about whether they both reference the same object, or whether the latter references any object at all. They may both be allowed and may even mean the same thing, but that depends on the implementation-defined representation of struct MyComplex (except that when n is zero, the two are always allowed and equivalent).

For example, if float has a four-byte representation, and the compiler happens to pad struct representations to multiples of 16 bytes, then some of the accesses of type (2) (intended to be to the real members via the float *) will be invalid.

It's worse for accessing the imag members: there you can also also be hosed if the compiler chooses to align each member on an 8-byte boundary, thereby requiring padding between real and imag.

Note, too, that padding is not necessarily even a fixed characteristic of implementations. Many compilers offer options that affect their padding decisions, so whether the code you're working with has defined behavior may depend on your compiler options.

John Bollinger
  • 160,171
  • 8
  • 81
  • 157
  • Yeah the padding thing definitely seems like a valid issue. Not saying I condone it, but on some platforms one could potentially skirt the issue by instructing the compiler not to pad the MyComplex struct (i.e. gcc's `pack()` pragma. Not something I'd want to have to rely on though... – mshildt Feb 10 '15 at 16:03
  • Code could use compile-time `offsetof` checks to ensure that objects have the same address. There is no way, however, to ensure whether a compiler given two pointers to unions of the same type will recognize that `&u1->member1` might alias `&u2->member2`, even in cases where the latter expression is evaluated between the last use of the former pointer and the first use of the latter. – supercat Sep 06 '17 at 21:18