Given that all places that need changing are byte buffers, why not switch to malloc and free instead?

Given that all places that need changing are byte buffers, why not switch to malloc and free instead?

I had the same thought. This PR will likely switch those lines to malloc but also resolve other potential new issues. This PR will take a lot of research and also a test project to demonstrate that it DOES resolve potential crashes.

I've decided to limit the scope of this PR to just replacing new with malloc in cases where a class constructor isn't called. This will limit conflicts with ongoing refactoring work. I'm not aware of any crashes related to missing nothrow, and from what I understand a class should have a nothrow variant to guarantee it won't crash.

Help needed: std::unique_ptr<uint8_t[]> buf(new uint8_t[bufSize]);

Reworked here: e20bcfa
Needs review!

Help needed: std::unique_ptr<uint8_t[]> buf(new uint8_t[bufSize]);

arduino-esp32/cores/esp32/Esp.cpp

Line 224 in 0d84018

std::unique_ptr<uint8_t[]> buf(new uint8_t[bufSize]);

Why did this use unique_ptr?

std::unique_ptr is a smart pointer that owns and manages another object through a pointer and disposes of that object when the unique_ptr goes out of scope. More or less it will automatically free the buffer on function exit

@me-no-dev What about this PR? Is it still valid?

Rebased PR on latest master. No conflicts. I'm open to suggestions on what parts of this PR you guys want to keep.

We should at least include the crash fix from #8065 to WiFiUDP.cpp. In fact, why didn't the fix on the 2.x branch get added to 3.x? Is it because we were going to merge this PR instead?

Is it because we were going to merge this PR instead?

Yes :)