struct hack

[Mark]

Hello,

I have a legacy code using 'struct hack' in many places, and I need to
update one of the structures with 'next' pointer creating linked list:

Was:
struct nhlfe_entry
{
u_int32_t nhlfe_ix;
owner_t owner;
u_char opcode;
u_int32_t refcount;

u_char flags;

enum entry_type type;
u_char nkey [1];
};

Will be:
struct nhlfe_entry
{
u_int32_t nhlfe_ix;
owner_t owner;
u_char opcode;
u_int32_t refcount;

u_char flags;

struct nhlfe_entry *next;

enum entry_type type;
u_char nkey [1];
};

I'm wondering if this might have any impact, such as alignment issues,
except that memory allocation for 'struct nhlfe_entry' may need to be
changed to accomodate 'next' pointer.

Thanks in advnce for any comments.

Mark.

 

[James Kuyper]

Hello,

I have a legacy code using 'struct hack' in many places, and I need to
update one of the structures with 'next' pointer creating linked list:

Was:
struct nhlfe_entry
{
u_int32_t nhlfe_ix;
owner_t owner;
u_char opcode;
u_int32_t refcount;

u_char flags;

enum entry_type type;
u_char nkey [1];
};

Will be:
struct nhlfe_entry
{
u_int32_t nhlfe_ix;
owner_t owner;
u_char opcode;
u_int32_t refcount;

u_char flags;

struct nhlfe_entry *next;

enum entry_type type;
u_char nkey [1];
};

I'm wondering if this might have any impact, such as alignment issues,
except that memory allocation for 'struct nhlfe_entry' may need to be
changed to accomodate 'next' pointer.

You're right to wonder about that. In principle, adding the 'next'
member might cause the alignment requirements of the structure to
change, though on many implementations it will have no effect. For
maximum portability, you should assume that it might.

However, for maximum portability, you also should not be using the
struct hack. Technically, it has undefined behavior, though in practice
it's likely to work as expected. If you can afford to limit your code's
portability to C99 or C2011 implementations, you should change it to use
a flexible array member, rather than the struct hack. The key difference
is in the declaration of nkey:

u_char nkey[];

If you can afford to limit your codes's portability to C99 or C2011
implementations, I'd also recommend considering changing u_int32_t to
uint_fast32_t, defined in <stdint.h> (or uint_least32_t or uint32_t,
whichever best fits your needs for that type).

 

[Barry Schwarz]

Hello,

I have a legacy code using 'struct hack' in many places, and I need to
update one of the structures with 'next' pointer creating linked list:

Was:
struct nhlfe_entry
{
u_int32_t nhlfe_ix;
owner_t owner;
u_char opcode;
u_int32_t refcount;

u_char flags;

enum entry_type type;
u_char nkey [1];
};

Will be:
struct nhlfe_entry
{
u_int32_t nhlfe_ix;
owner_t owner;

Since we don't know what owner_t is, we cannot tell if it's alignment
requirement is more or less stringent than pointer to struct.

u_char opcode;
u_int32_t refcount;

u_char flags;

struct nhlfe_entry *next;

On a 64 bit system, this may require 8-byte alignment. If owner_t did
not, this may affect both the alignment and internal padding of struct
nhlfe_entry.

enum entry_type type;
u_char nkey [1];
};

I'm wondering if this might have any impact, such as alignment issues,
except that memory allocation for 'struct nhlfe_entry' may need to be
changed to accomodate 'next' pointer.

You should not be hardcoding allocation quantities. If you are using
malloc, the argument should be of the form
sizeof(struct nhlfe_entry)+size_of_the_dynamic_character_array
If the return value is being assigned to a pointer to struct
nhlfe_entry named ptr, then it is easier to code the first expression
as the equivalent
sizeof *ptr
Then, regardless of what changes you make to the structure type, the
sizeof expression will always adjust automatically when you recompile.

 

[James Kuyper]

Since we don't know what owner_t is, we cannot tell if it's alignment
requirement is more or less stringent than pointer to struct.

Even if we did know what owner_t is, we might still not be able to
determine that. There's precious little that can be said about which
types are more strictly aligned than others, that's portably true.