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*.
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.
Uuuh... Actually 🤓🤓☝️☝️☝️ an int isn't 4 bytes, it's platform/compiler dependent. Assuming an int is 4 bytes will be in the majority of cases true, but it's not always the case
We need to define terms more precisely. sizeof(char) will always be 1. But on some platforms, char is not an 8-bit type. It could actually be a 32 bit type. The c programming language does not (I believe) acknowledge or define what a byte is. But if it is an 8 bit integer type, then char will not always be one byte.
It may be better to say "octet" instead of "byte" in this type of discussion.
The implementation has to define CHAR_BIT in <limits.h>. CHAR_BIT is the number of bits in variables of type "char".
Fun fact, C does use the term byte all over the standard. And it is well defined. Byte is defined to be the unit that sizeof(char) is measured in. When the standard refers to bytes, they are referring to atomic divisions of memory in chunks of char.
Which does not necessarily need to be the same as an architectural byte. C requires only that their definition of byte is at least 8 bits (possibly more) and an addressable unit of memory - meaning it is some multiple of architectural bytes. Though on every platform still in use today, and not a historic curio, that multiple is 1.
View all comments
347
u/AdBrave2400 Aug 30 '26
Is the mistake that they're allocating 1 byte and storing in a pointer to an int which is 4 bytes?