C语言中任意内存的类型

Question

This is in reference to this question

How to implement the c malloc/realloc functions properly?

where the accepted answer mentions that a char array can be used to model a pool of arbitrary memory.

However one of the comments to that accepted answer states

A char array that doesn't have allocated storage duration can only be aliased by a character type. In other words it cannot and it should not be used as arbitrary memory

Is this correct? If so, then what could be used? I'd like to avoid using alloc or any specific OS calls - so I'm symmetrical with that question.

Answer 1

There are different problems around. First as shown by @Magisch's answer the related question was returning a dangling pointer causing Undefined Behaviour and generally execution errors.

The second one is related to the @^*# (censorship here) strict aliasing rule. Common compilers produce correct code when you use a character array as a large buffer to allocate any type from it, provided you ensure correct alignment. After all, this is the way they have to implement the malloc , realloc , and free routines. And as they are part of the hosted environment (C standard library), the compiler developpers are not masochist enough to fordib that usage.

But the C standard is a bit more strict here. You should read my own answer here to a similar question and particularly @EOF's comment to it:

You cannot parcel of parts of an object declared as char [] into objects of other types (except character types), because they do have a declared type... which means technically you can't implement malloc() in pure C

Answer 2

Aliasing refers to the strict aliasing rule that governs how the compiler is allowed to use registers. If you have pointers of different type referring to the same memory location, then writing done through one pointer type may not be noticed when reading through the other pointer type because the compiler is allowed to cache the data in registers.

When you implement a memory pool, this problem is usually moot, because the pool implementation doesn't read/write to the memory.

If you want arbitrary types, then the safest bet is a union. Not only will it "beat" the strict aliasing rule, it will also ensure correct alignment. Remember that malloc and friends ensure alignment suitable for any type while auto doesn't.

Answer 3

The issue is alignment. On processors that have alignment restrictions, a char array may not start at an address suitable for storing larger objects, like int or double .

So to be safe, you need to make sure the char array is aligned properly for any type. If you're using a C11 compiler, then you can force alignment like this

#include <stddef.h>
#include <stdalign.h>

_Alignas(max_align_t) char buffer[SIZE];

For older compilers, __attribute__((aligned(SIZE))) may be a solution. Otherwise, you need to look for a #pragma that forces alignment.

And as discussed in various comments/answers, you should definitely disable the strict aliasing optimization with the -fno-strict-aliasing option. If that option (or the equivalent) doesn't exist, then you need to determine the optimization level that relies on the strict aliasing rule, and only use a lower optimization level.

Answer 4

I believe the issue he pointed out was that if you allocate a char type array statically and then compile your library with a modern, desktop-like C compiler like gcc, you cannot easily convert the contents of that area to another type. Because then the compiler would perform optimizations based on pointer aliasing and screw everything up, see "the strict aliasing rule" .

Simply assure that your compiler does not use strict aliasing and you'll be fine. For example, none of the common embedded systems compilers on the market does this.

With gcc you'd compile as -fno-strict-aliasing . Might be good to always enable warnings for code that would cause such problems -Wstrict-aliasing .

As a side note, uint8_t makes far more sense to use as generic type, because unlike char , it is completely unambiguous: it has no signedness and the size is well-known.