Preprocessor definition causing build failures

[Kreeblah]

I'm not really sure what the best way to go about addressing this is, given how common this call is, but in mem/mem.h, there's the following definition:

#define free(ptr)       do{ mem_free(ptr); ptr=NULL; } while(0)

This causes the following error when building on macOS:

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/c++/v1/new:330:5: error: expected unqualified-id
  ::free(__ptr);
    ^
/Users/kreeblah/ChocolateDescent/./mem/mem.h:26:25: note: expanded from macro 'free'
#define free(ptr)       do{ mem_free(ptr); ptr=NULL; } while(0)

That definition can be ifdefd away, but then it'd lose the guarantee of ptr being NULL afterwards. Alternately, these definitions could be renamed to be specific to this project, but it'd be easy to forget that and use the regular methods instead. There might be other ways of fixing this, too, but those are the two I was able to come up with off the top of my head.

I'm happy to do some work to fix this to get the project building on macOS again, but I was hoping to get your thoughts on your preferred way to go about it first.

[InsanityBringer]

I'm not opposed to changing the name, honestly. I may just replace it with a constexpr function with some unique name that takes a ref to a void* pointer to ensure the same functionality of setting nullptr when done. I'll give that a try quickly.

[InsanityBringer]

I've chosen to address this ATM by renaming them but keeping them as macros. Main reason is that to make them functions would require std::source_location, which I'm unaware of compiler support for ATM (ie VS 2019 doesn't seem to have it, though VS 2022 should?)

[Kreeblah]

Makes sense. It builds for me now with that change, so I'm all good now.

Thank you!