The behaviour is implementation defined, you will receive either a NULL pointer or an address. Calling free for the received pointer should however not cause a problem since: free(NULL) is ok, no operation is done free(address) is ok, if address was received from malloc (or others like calloc etc.)
There’s no new/delete equivalent of realloc in C++. From Bjarne Stroustrup’s FAQ : Why doesn’t C++ have an equivalent to realloc()? If you want to, you can of course use realloc(). However, realloc() is only guaranteed to work on arrays allocated by malloc() (and similar functions) containing objects without user-defined copy constructors. Also, please remember … Read more
I assume you mean something like this: int *iptr = (int*)malloc(/* something */); And in C, you do not have to (and should not) cast the return pointer from malloc. It’s a void * and in C, it is implicitly converted to another pointer type. int *iptr = malloc(/* something */); Is the preferred form. … Read more
C doesn’t enforce any array bounds checking, so while you requested space for 5 integers, you used more. In fact you overwrote 4 memory locations that really weren’t set aside for your specific purpose. Your program went past the area in memory that was set aside for your array, and started to store values in … Read more
So shouldn’t the following be the correct way to dynamically allocate a 2d array? It should, since this approach is the equivalent of declaring a “statically-allocated” array of multiple dimensions. The reason for this is that this way, you get a contiguous block of memory, which is convenient (you couldn’t use memset() on a pointer-to-pointer, … Read more
If you declare int array[variable] the memory will be allocated on the stack which is not very good for large, relatively permanent data structures (such as one you might want to return). You don’t need to free memory manually if you use the array syntax since it’s freed when it goes out of scope. calloc … Read more
You can do it like this: *(int *)0x16 = 10; // store int value 10 at address 0x16 Note that this assumes that address 0x16 is writeable – in most cases this will generate an exception. Typically you will only ever do this kind of thing for embedded code etc where there is no OS … Read more
If you need that block for storing null-terminated string then yes, you need to explictly ask malloc() to allocate an extra byte for storing the null-terminator, malloc() will not do it for you otherwise. If you intend to store the string length somewhere else and so you don’t need the null terminator you can get … Read more
First, Malloc makes no guarantees that two successive malloc calls return successive pointers. Second, depending on your specific architecture, different alignment rules apply; sometimes you might ask for a single byte, but the architecture prefers allocations on 8- or 4-byte intervals. Third, malloc needs some overhead to store how big the allocated block is, etc. … Read more
If you do so you will run into undefined behavior. Never try that. Although new might be implemented through malloc() and delete might be implemented through free() there’s no guarantee that they are really implemented that way and also the user can overload new and delete at his discretion. You risk running into heap corruption. … Read more