Hi Timothy/ The code below is kind of a C-trick (or hack) based on the knowledge of how the C-compiler lays out structs in memory. In your example it would be: struct layout +------+ | a +------+ | b +------+ | _data[0] +------+ Adding the +64, gives you 64 extra bytes (64/4) = 16 int's if sizeof(int) is 4 (32-bit)), making the layout look like: +------+ | a +------+ | b +------+ | _data[0] +------+ | +1 +------+ | +2 +------+ | . . . +------+ | +16 +------+ So now you can safely address tmp._data[15] = 0x12345678 ; // last element in struct I don't know your need, but I don't think C was intended to be used like this, best practice is: 1) Hard allocate memory #define SIZE 16 typedef struct foo_t { int a, b; int _data[SIZE]; } 2) Dynamic allocate memory typedef struct foo_t { int a, b; int* _data; struct tmp = foo_t; tmp._data = malloc(64) 3) Hack alloc - see above :-)

On 30 Oct 2018, at 00.41, Timothy Baldridge <tbaldridge@gmail.com> wrote:

Looking at rbuffer, rgc, and the lltype namespaces, it's not completely clear to me how I would go about writing a struct with a resizable primitive array inlined.

Something like:

typedef struct foo_t { int a, b; int _data[0]; }

foo_t tmp = malloc(sizeof(foo_t) + 64);

malloc() returns a pointer, so It should be foo_t* tmp = (foo_t*) malloc(sizeof(foo_t) + 64);

I can see that the GC has the ability to allocate "extra" memory beyond what's required for a struct, and that lltype has the ability to inline some lists into a struct, but how does this work in practice? And maybe I'm missing something in the docs, so simply pointing me to some docs is also fine.

Not sure where to find this, it is sometimes used, but I am not sure I would recommend it, unless you know exactly what your are doing and like keeping track of allocated memory :-) br /Rene

-- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) _______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev

Hi Timothy/ The code below is kind of a C-trick (or hack) based on the knowledge of how the C-compiler lays out structs in memory. In your example it would be: struct layout +------+ | a +------+ | b +------+ | _data[0] +------+ Adding the +64, gives you 64 extra bytes (64/4) = 16 int's if sizeof(int) is 4 (32-bit)), making the layout look like: +------+ | a +------+ | b +------+ | _data[0] +------+ | +1 +------+ | +2 +------+ | . . . +------+ | +16 +------+ So now you can safely address tmp._data[15] = 0x12345678 ; // last element in struct I don't know your need, but I don't think C was intended to be used like this, best practice is: 1) Hard allocate memory #define SIZE 16 typedef struct foo_t { int a, b; int _data[SIZE]; } 2) Dynamic allocate memory typedef struct foo_t { int a, b; int* _data; struct tmp = foo_t; tmp._data = malloc(64) 3) Hack alloc - see above :-)

On 30 Oct 2018, at 00.41, Timothy Baldridge <tbaldridge@gmail.com> wrote:

Looking at rbuffer, rgc, and the lltype namespaces, it's not completely clear to me how I would go about writing a struct with a resizable primitive array inlined.

Something like:

typedef struct foo_t { int a, b; int _data[0]; }

foo_t tmp = malloc(sizeof(foo_t) + 64);

malloc() returns a pointer, so It should be foo_t* tmp = (foo_t*) malloc(sizeof(foo_t) + 64);

I can see that the GC has the ability to allocate "extra" memory beyond what's required for a struct, and that lltype has the ability to inline some lists into a struct, but how does this work in practice? And maybe I'm missing something in the docs, so simply pointing me to some docs is also fine.

Not sure where to find this, it is sometimes used, but I am not sure I would recommend it, unless you know exactly what your are doing and like keeping track of allocated memory :-) br /Rene

-- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) _______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev