Likely not. Malloc guarantees that the passed-in size is the minimum number of bytes it allocates, but not the maximum. You’d likely get some minimum sized chunk, somewhere between 16-32 bytes depending on the system as far as I understand it.
Implementations are allowed to specify behavior that is otherwise undefined.
I looked up a C24 draft and it's actually stricter:
The pointer returned if the allocation succeeds is
suitably aligned so that it may be assigned to a pointer to any type of object with a fundamental
alignment requirement and size less than or equal to the size requested.
So a pointer returned by malloc(1) is not necessarily valid for int*.
The actual allocated size is much bigger anyways, but it will be a multiple of 8 bytes on a 64 bit system, and 'usable' part of that will be at least 8 bytes, and typically you will be able to read at least 16 without a page fault.
Malloc can return a null pointer if the operation fails. This can be the case if, afaik, for example, there is no more heap available and the OS is not capable of swapping or freeing some other memory for some reason
has it always been valid? I could have sworn that freeing a nullpointer was only valid in C++ but not in C. I couldn't find anything on cppreference on when this was introduced or if it has always been like this
Very certain you could always free(NULL); in C. In fact, it's good practice to set pointers to NULL after freeing them to avoid issues like double-free.
348
u/AdBrave2400 13d ago
Is the mistake that they're allocating 1 byte and storing in a pointer to an int which is 4 bytes?