将成员地址分配给struct中的其他成员

Question

Is the following safe in C?

struct Buffer {
  size_t size;
  int8_t *storage;
};

struct Context {
  struct Buffer buffer;
  int8_t my_storage[10];
};

struct Context my_context = {
  .buffer = {
    .size = 0,
    .storage = my_context.my_storage,
  },
  .my_storage = {0},
};

I am working with a micro controller and I don't want to have to use malloc. Also, to me it looks better to collect everything in the struct rather than have the storage as a separate variable outside the Context.

[edit1] I have tested it and it compiles and works, as in the pointers to my_context.my_storage and my_context.buffer.storage are the same, with gcc (Debian 4.7.2-5) 4.7.2 on Linux ... 3.2.0-4-amd64 #1 SMP Debian 3.2.65-1+deb7u2 x86_64 GNU/Linux

[edit2] In an answer that was later deleted I was referred to C99 standard section 6.7.8-19 "The initialization shall occur in initializer list order..." Would that mean that

struct Context my_context = {
  .my_storage = {0},
  .buffer = {
    .size = 0,
    .storage = my_context.my_storage,
  },
};

Is guaranteed to be safe? I interpret it that way.

[edit3] Below is a full working example.

#include <inttypes.h>
#include <stdio.h>
#include <stdlib.h>

struct Buffer {
  size_t size;
  int8_t *storage;
};

struct Context {
  struct Buffer buffer;
  int8_t my_storage[10];
};

struct Context my_context = {
  .buffer = {
    .size = 0,
    .storage = my_context.my_storage,
  },
  .my_storage = {0},
};

int
main(void)
{
  printf ("ptr points to: %" PRIXPTR "\n", (uintptr_t)my_context.buffer.storage);
  printf ("storage is at: %" PRIXPTR "\n", (uintptr_t)my_context.my_storage);
}

>> ./test
ptr points to: 600950
storage is at: 600950

Answer 1

Yes, this is fine. Assuming my_context has automatic storage duration, its lifetime begins on entry to the associated block, and during its lifetime it has a constant address ( 6.2.4 Storage durations of objects /2). (If it has static or thread storage duration instead, then its lifetime extends for the duration of the entire program or thread respectively).

It follows that my_context.my_storage also has a constant address over the lifetime of my_context , so taking its address (via array-to-pointer decay) for the initialization of my_context.buffer.storage will give the same value as it would after the initialization of my_context is complete.

Also note that the scope of my_context begins at the point its declaration is complete, which is just prior to the = of the initializer, so referring to it within its initializer is also fine.

Answer 2

This doesn't really have anything to do with designated initializers and the order of initialization. What you are actually asking is if something like this is well-defined:

typedef struct
{
  int* ptr;
  int  val; 
} struct_t;

struct_t s = {&s.val, 0};

And yes, I don't see why it shouldn't be. The compiler has to allocate s at an address in memory before attempting to initialize it. The order in which the struct members is allocated or initialized shouldn't matter.

---

However , writing initialization lists where one value of a struct depends on another value of the same struct is not safe! C11 6.7.9/23 says:

The evaluations of the initialization list expressions are indeterminately sequenced with respect to one another and thus the order in which any side effects occur is unspecified.

Assignment of a value to a variable is a "side effect". So code like this is unsafe:

typedef struct
{
  int  val1; 
  int  val2;
} struct_t;

struct_t s = {0, s.val1};

Because the compiler may evaluate the two expressions of the initializer list like this:

• s.val1 -> evaluate to the contents of val1 (garbage, it has not been initialized)
• 0 -> evaluate to 0
• write evaluated value (0) to val1, guaranteed to happen before:
• write evaluated value (garbage) to val2

So even though the initialization order is guaranteed, the order of evaluation of the initialization list is not. Though of course the compiler may have decided to evaluate the 0 expression first and then everything would have worked fine.

The bottom line is, don't write obscure initialization lists.