[ERSUCC]

When compiling RtAudio on Mac with Clang, it threw a few warnings about arrays being allocated with variable length. Converting these stack arrays to heap arrays with malloc resolved the warnings.

[nmq443]

Should we use std::string instead of char* here? So that RAII will handle freeing resource for us, instead of using malloc()/free() manually

[nmq443]

Hello @ERSUCC
I know it is a little late but I have added some comments about your changes. I don't have a Mac so I don't know if my comments will help or not. Please correct me if I am wrong.
Thanks

[ERSUCC]

@nmq443 Thank you for your comments! None of those functions are marked as noexcept, so you're right that there could be a memory leak. However, I don't think using std::vector is a good solution for any of these cases, because all of them are out parameters. It is possible to get the underlying pointer to a std::vector with .data(), but it feels kind of wrong to let an external function write to that underlying buffer instead of using the methods in the std::vector class, and I don't think that's the intended use of .data(). Also, I'm not a fan of using std::vector when the size of the array is known and constant; it just adds extra infrastructure.

My preferred solution would be to catch exceptions from these external functions, free the malloc'd array, and rethrow the exception. But also, if an exception occurs that prevents RtAudio from being initialized, there isn't much hope for the user's program anyway, so I doubt that this memory leak would be consequential in the first place. Either way, I'm happy to amend my PR with try/catch as necessary, if that seems like a good solution.

[nmq443]

@ERSUCC Your comment about std::vector::data() sounds reasonable to me. Also I have just doing some research, using .data() to let a C API write into a vector's buffer is legal (since C++11, the buffer is guaranteed contiguous) but it does bypass the vector's size-tracking invariant, meaning the vector doesn't know the C function filled it, so .size() stays whatever it was. That's dangerous if someone later assumes vec.size() reflects valid data.
About your solution, have you considered std::array if the size is truly compile-time constant, or std::unique_ptr<Type[]> if it's runtime-determined? Either gives you exception safety for free without the manual try/catch/free/rethrow, and avoids the malloc/free C-style pattern entirely. I read the code around your malloc, and see the size variable are runtime-determined mostly, for example:

result = AudioObjectGetPropertyDataSize( id, &property, 0, NULL, &dataSize ); // line 1345
UInt32 nRanges = dataSize / sizeof( AudioValueRange ); // line 1353

So may be std::unique_ptr<Type[]> can be used. But I don't know if this std::unique_ptr<Type[]> is preferred in production or not, so can you please review it for me?

Thank you!

[ERSUCC]

Yes, std::unique_ptr would do the trick. I didn't know that you could use it for malloc'd arrays, but I did a little test and it seemed to work as expected. I will update my solution to use std::unique_ptr when I get the chance. Thank you for the suggestions!