How do you return a char array in C++?

[you2]

No; you can roll your own malloc safely. The real head-ache is beating what is available. So if you don't like the existing scheme copy one that you like and link it with your code. Not sure why you feel malloc implementation are more prone to security issues than using char *.
-
The use of malloc is consider a security issue due to frequently coding errors that result in out of bound writes; but that is not an issue with the implementation of malloc per sey but rather the coding practice that sometime occur with the usage of malloc. HOWEVER this is tangent to the implementation of malloc.
-
So yes I agree with you that some coders who use malloc are sloppy and therefore may have security issues but those issues are not with the implementation of malloc but rather coding style/languages that allow for easy access to unassigned memory (memory not assigned to a specific variable). That is the advantage (for example) of stl strings vs char * (though a strongly typed language like java is more 'secure' than a weakly type lanugage like c/c++.

I was with you right up to the last sentence. Rolling your own malloc is generally a huge security risk!

 

[Ken g6]

True, char* is also a decently bad security risk. I was trying to remember where someone's malloc re-implementation caused a security problem - it was Heartbleed. Not a problem with out-of-bound writes, but a problem with saved existing writes...which is even more likely to be a problem with char*.

So I guess you need to malloc with Strings. Or more likely just don't use an Arduino in an application where security is paramount.

 

[you2]

Well I tihnk we can write decently secure software on Arduino; you just have to pay attention to your bound(aries).

 

[Red Squirrel]

Stupid question but is there any reason to use malloc over new? I always use new and delete myself. For this particular instance I was not really declaring new memory just trying to find out the syntax to "return" an array through an argument, which I got working. (example in post 7)

 

[Merad]

malloc allocates and returns a raw chunk of memory. new allocates *and* runs constructors to initialize an object in the chunk of memory. new should be used 98% of the time in a C++ program.

 

[mv2devnull]

new should be used 98% of the time in a C++ program.

Standard library tools (e.g. std::make_unique) should be used most of the time. When that is not feasible, call new directly. When all those are not an option, malloc might be appropriate.

 

[Cogman]

Standard library tools (e.g. std::make_unique) should be used most of the time. When that is not feasible, call new directly. When all those are not an option, malloc might be appropriate.

Bingo. new/delete should be avoided and make_unique and make_shared should be preferred (with make_unique being the right one 98% of the time).

New and delete are only for when you want a shared pointer and the overhead of reference counting is too expensive. make_unique has 0 overhead which is why it should be used wherever possible.

 

[Red Squirrel]

Hmm never heard of make_unique. I usually use new/delete but typically within classes and not directly. Ex: if I make a base class that is to be used for a certain purpose, the class will take care of the memory handling, then I use the class within the program. I have a tcp/ip class I wrote that uses a few internal pointers for example.

 

[Cogman]

That is the "old" style of C++. Nothing particularly terrible about it, however, make_unique makes it really hard to get wrong. Manual memory/lifecycle management just has all sorts of potentially dangerous bits that are all nicely handled by make_unique.

A good example of the trickiness is constructors. Ask yourself "What happens if there is an exception thrown in the constructor?"

For example, what if your object contains a file manipulation resource? The C++ standard says that all of the initialized members get their destructors called. However, if you've newed something up, it does not get deleted and the destructor does not get called.

That means, to be totally safe when doing new in a constructor, you would have to do something like this

Thing() {
  try {
    this.tim = nullptr;
    this.tim = new Bob();
    this.fred = nullptr;
    this.fred = new Jim();
  } 
  catch
  {
    if (tim != nullptr)
       delete tim;
    if (fred != nullptr)
       delete fred;
  }
}

pretty horrible, huh.

unique and shared ptr do away with that. You can write something like this

Thing() {
  using namespace std;
  this.tim = make_unique<Bob>();
  this.fred = make_unique<Jim>();
}

Now if either tim or fred die in construction (or some other exception happens during construction) either will get deallocated and their destructors called.

 

[mv2devnull]

Hmm never heard of make_unique.

The std::make_unique was added in C++14, while the std::make_shared was already in C++11.