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 <tbaldri...@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
_______________________________________________
pypy-dev mailing list
pypy-dev@python.org
https://mail.python.org/mailman/listinfo/pypy-dev
