Closed Anthony-Nicholls closed 2 weeks ago
Oh god..
Just stepping back for a moment here, this is all just so we can throw an exception if there's a stack overflow... Is it actually possible to throw a C++ exception when there's a stack overflow? Or is there another version of alloca on windows that returns an error value instead of throwing?
..I guess what's bothering me is the idea that choc_Value.h needs to include windows.h just to handle this ridiculously edge-casey situation..
Oh god..
Just stepping back for a moment here, this is all just so we can throw an exception if there's a stack overflow... Is it actually possible to throw a C++ exception when there's a stack overflow? Or is there another version of alloca on windows that returns an error value instead of throwing?
No, not interested in trying to throw an exception really. It might be possible but I don't see the point. This is just to keep the compilers happy
_alloca
instead, MSVC produces a compiler warning telling us to use _malloca
(we don't want that as it might allocate on the heap) or wrap the call with __try
/ __except
__try
/ __except
but don't catch a specific exception, MSVC produces a different compiler warning__try
/ __except
but compile using anything other than MSVC (clang or MinGW), the compiler will produce yet another warning or errorI was initially trying to avoid pragma ignores (as most of the choc codebase does) but I think that's the best way forward, what about something along these lines (untested), I think this closely mirrors what JUCE is doing.
static inline void* stackAllocate (size_t size)
{
#if _MSC_VER
#pragma warning push
#pragma warning (disable: 6255 6386)
return _alloca (size);
#pragma warning pop
#else
return alloca (size);
#endif
}
Can you call alloca inside a function and return the result? Unless the compiler definitely inlines the function, surely the memory would go out of scope at the end of the function?
Can you call alloca inside a function and return the result? Unless the compiler definitely inlines the function, surely the memory would go out of scope at the end of the function?
haha nope! OK ignore the function that was me trying to be too clean and not thinking straight, but the rest is still relevant.
I've got the code I've pushed here also building on JUCE CI I'll let you know how it goes.
OK, I can go with that
OK all tests are passing now. It's only the last commit that actually matters, I'll let you decide if you want to do anything with the other two commits or not, they're not needed for JUCE at all.
Cheers. I think I'll leave the windows header thing for now. Although in general I always try to de-dupe code like that, in choc I also try to reduce the number of other choc files that each one depends on, so allow a little bit of code duplication to creep in for that.
Unfortunately the recent change to avoid
GetExceptionCode() == STATUS_STACK_OVERFLOW
caused another warning (warning C6320: Exception-filter expression is the constant EXCEPTION_EXECUTE_HANDLER. This might mask exceptions that were not intended to be handled.
) however, as you had already discovered the use ofGetExceptionCode()
andSTATUS_STACK_OVERFLOW
were also causing issues becauseWindows.h
wasn't included. In this PR I think I've managed to fix all those issues 🤞 and avoid any pragma ignore warning malarky too. Hopefully that will be the last of it!