- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
// http://p99.gforge.inria.fr/p99-html/group__flexible.html
//C99 allows a flexible array member to be defined as the last member of a struct,
// namely an array of undetermined length.
//P99_DECLARE_STRUCT(package_head);
struct package_head {
char name[20];
size_t len;
uint64_t data[];
};
// Such a struct can then be allocated on the heap with a suitable size such
// that the field data has as many elements as fit in the allocated space from
// the start of data onward. Usually one would allocate such struct with
package_head *a = malloc(sizeof(package_head) + 10 * sizeof(uint64_t));
package_head *b = malloc(sizeof(*b) + 12 * sizeof(b->data[0]));
// This has several disadvantages. Firstly, the syntax is clumsy. We have to
// use a relatively complicated expression that uses two elements of the specification of a or b.
// Secondly, it wastes space. Due to packing of the struct the offset of data "inside"
// the struct may be less than sizeof(package_head). In most cases the real size
// of the object that we want to construct is
offsetof(package_head, data) + N * sizeof(uint64_t)
// so we are wasting
sizeof(package_head) - offsetof(package_head, data)
// bytes.
// The above formula for the exact size is only valid for larger values of N. We must
// also ensure that we allocate at least sizeof(package_head) bytes. So the complete
// formula looks something like
#define P99_FSIZEOF(T, F, N) P99_MAXOF(sizeof(T), offsetof(T, F) + P99_SIZEOF(T, F[0]) * N)
// which is probably not something that you want to write on a daily basis.
// We provide several interfaces to allocate struct with flexible members
Херню написали какую-то. Забыли самое главное : нельзя так в лоб аллоцировать память под структуры. Потому что выравнивание может не то быть.
Надо использовать http://man7.org/linux/man-pages/man3/aligned_alloc.3.html
Follow us!
Т.е. realloc не дурак.
> Regular malloc aligns memory suitable for any object type (which, in practice, means that it is aligned to alignof(max_align_t)). This function is useful for over-aligned allocations, such as to SSE, cache line, or VM page boundary.
Именно поэтому я за сатаническую память.
На 64-битке вроде даже 16 тратится под это.
на 32 битах: 16 байт выравнивание, перед блоком 4 байта с размером занятого блока + 1 (или | 1 ? наверное это флажок занят/свободен), размер блока кратен 16;
на 64: та же хуйня, но размеры в джва раза больше.
Кстати, а есть целочисленный тип, который для любой платформы будет размером с указатель?
Странно, что всего одно число. Как они из такого списка потом удаляют? Не пробегать же всю кучу по порядку.
Если у меня структура весит 5 байт, то в ней может таиться dword, т.е. начало должно быть выровнено хотя бы на 4?
Мне кажецца что нуль должно быть, не зря же можно ещё и huint64_t data[0]. Но гцц молчит как пармизан: