Thread: Increasing The Size of Memory Allocated to a Struct via Malloc

In the most recent C standard (C99), the last member of a structure may be a variable-sized array, so maybe that's what's going on. Try compiling under strict ANSI rules (-ansi on gcc) and see what happens.

Malloc just returns a block of bytes, it doesn't know what type of object you're trying to allocate. So you get a block of size ( sizeof(struct test) + sizeof(int) * 9 ) bytes. You tell the compiler to point a struct test pointer at it. So you're correct, you're using the last member of the struct as a point from which to access you're "extra" bytes.

This would do well in a code obfuscation contest, not in the real world.

@iMalc, good points, and it made things more clear.

Thanks.

Originally Posted by envec83

My questions for the experienced C programmers out there:

1. What is happening behind the scenes here?

Pure and unmitigated dumb luck. Try this in a more complex program and it's likely to do all kinds of strange stuff. You are playing with undefined behavior and the outcome will depend on the compiler, usage of the variables and the order in which the struct is stored in memory.

Earlier versions of windows used to to this (WNet network enumerator still does). You would get back a memory buffer with an array of structs and all the strings are stored behind the array in memory... It does work, but it's not exactly the safest way to do things, buffer overruns and struct misalignment were common problems.

2. Does this trick only works when there is an array inside the struct?

AND only when the array is stored at the end of the stuct... anywhere else, as iMalc points out, all you're going to do is overwrite the other struct members.

O_o

It is undefined behavior according to the standards committee by virtue of not being address, but this "struct hack" method is as common as dirt and unless you have a bad compiler or a platform that violates parts of the standard you'll be fine.

Compilers that attempt to implement C99 are more free in this regard, but it so happens that "flexible array members" are a required part of that standard.

It works basically the same as having these three structures:

Code:

struct base
{
    int size;
};

struct core
{
    int size;
    int i[1];
};

struct big
{
    int size;
    int i[100];
};

The standard demands that the `size' member be correctly addressable if you allocate any of these structures and cast the result to a pointer to any of these structures. Further, the one element of the `i' array must also be addressable in the case of `core' and `big'. Finally, the standard demands a regular approach to indirectly addressing elements of an array. Basically, if your compiler conforms to all of those parts of the standard, and doesn't implement bounds checking, your walking on undefined but highly reliable behavior.

Ultimately, you may find a compiler that produces code that doesn't work or emits a warning/error, but in practice it is widely available with well defined semantics.

Oh, as for it being "dumb luck" or a problem in "complex programs", you'll find it used a lot in the "Linux" kernel, "Oracles" database systems, and a lot of "FreeBSD" bits.

Soma