Is it safe to use the "realloc" after the "new" operator in C++?

Question

As far as I know, there is no exact alternative for the realloc of C in C++ like the new for malloc. However, when I use the realloc in C++ to alter the memory allocated by the new operator, it works fine.

Is it safe to use those two (new and realloc) like I do in the codes below or it can lead to some problems?

#include <iostream>
#include <cstdlib>

int main()
{
    int size = 5;
    int * arr = new int[size]{ 1,3,5,7,9 };

    for (int i = 0; i < size; i++)
        std::cout << *(arr + i) << (i < size - 1 ? ' ' : '\n');

    size++;
    arr = (int*)realloc(arr, size * sizeof(int));

    *(arr + size - 1) = 11;
    for (int i = 0; i < size; i++)
        std::cout << *(arr + i) << (i < size - 1 ? ' ' : '\n');

    delete[] arr;
    //free(arr);

    std::cin.get();
    return 0;
}

Also, which operator should I use in such a case to free the memory: delete[] of free()?

The runtime library just doesn't go out of its way to make this intentionally fail. It is however flaming UB when the element type is a C++ object, like std::string. Internal pointers won't get updated. — Hans Passant, Jul 09 '18 at 14:07
@HansPassant Why on earth would anyone do this with a `std::string`? Or indeed any kind of library object? Everything to lose, nothing to gain (unless perhaps you thoroughly misunderstand `std::vector` or `std::array`). — Paul Sanders, Jul 09 '18 at 17:28
And, interestingly, because `new` and `malloc` allocated from different heaps, "Edit n Continue" didn't work in VS2015, I think it was, because - as I discovered after a fair bit of digging - something was allocated with `malloc` and later freed with `delete`. I patched `mspdsrv` and sailed on my merry way (it got fixed later). Ironically, the bug was 'swallowed' by some invalid parameter handling logic so the developer who made this boo-boo never saw any evidence of it (other than the fact that his code didn't actually work). — Paul Sanders, Jul 09 '18 at 17:28

score 4 · Accepted Answer · edited Jul 09 '18 at 14:09

4

No, the behaviour is undefined. You can only call delete[] on a pointer that you've obtained from a call to new[].

Using std::vector would cause all these memory issues to fall away.

edited Jul 09 '18 at 14:09

George

2,101
1
13
27

answered Jul 09 '18 at 14:05

Bathsheba

231,907
34
361
483

[documentation of realloc says](https://en.cppreference.com/w/c/memory/realloc): Reallocates the given area of memory. It must be previously allocated by malloc(), calloc() or realloc() and not yet freed with a call to free or realloc. Otherwise, the results are undefined. – Paul Belanger Jul 09 '18 at 14:56

score 2 · Answer 2 · answered Jul 09 '18 at 14:04

It is not safe. new should only be matched by delete or delete[] - using it with realloc is dangerous and could lead to security risks.

Also, why are you using new and delete in the first place? Use containers like std::vector or smart pointers such as std::unique_ptr if you really want to manage memory yourself.

score 0 · Answer 3 · answered Jul 09 '18 at 14:04

0

Don't mix c memory functions with c++ memory functions or you're gonna have a bad time.

See this: What is C++ version of realloc(), to allocate the new buffer and copy the contents from the old one?

answered Jul 09 '18 at 14:04

Hongyu Wang

378
1
10

2

As is this answer should be a comment – NathanOliver Jul 09 '18 at 14:05

Is it safe to use the "realloc" after the "new" operator in C++?

3 Answers3