[openal] Making functions noexcept

[Chris Robinson]

Hi,

As a C-based API, OpenAL doesn't deal with C++ exceptions. The functions 
have C linkage, the spec doesn't define any exceptions, and a C-based 
caller would have no easy way to correctly deal with one anyway (or any 
other non-C++ language that can directly call the functions).

A C++ caller, however, still needs to assume a function with C linkage 
can throw an exception, if not specified otherwise with the noexcept 
keyword[1], which can put an unnecessary burden on the caller. An 
implementation written in C++ also needs to take extra care to not let 
an errant exception escape back to the caller on accident, requiring 
extra try/catch protections for each external function.

[1] MSVC does have an option to treat all functions with C linkage as 
noexcept, but GCC/Clang don't as far as I'm aware. Technically this may 
even be against the C++ spec, which says that the functions it inherits 
from C can be noexcept except those that take a callback (e.g. qsort is 
not supposed to be noexcept, and the callback is allowed to throw), 
making it not ideal to rely on.


So, what I'd like to do is update the header declarations to include 
noexcept when compiling as C++. When compiling as C++17 or later, the 
function pointer typedefs can/should also be marked noexcept, otherwise 
code that uses the typedefs to define, load, and use OpenAL dynamically 
won't benefit. This would have no bearing at all on C code, or other 
non-C++ languages that access them as a C function. For C++ callers, it 
allows the compiler to know the calls won't throw an exception and 
optimize accordingly, and C++ implementations wouldn't be able to let 
exceptions escape back to the caller as the functions would be noexcept.

There is, however, a small potential for API incompatibility, which is 
causing me some hesitation. ABI is fine, apps and binaries built using 
non-noexcept headers will still work without issue at runtime, but some 
C++ code made for non-noexcept headers could potentially have issues 
(re)compiling with updated noexcept headers. In particular, if the code 
had defined its own AL-like fallback functions or callbacks without 
noexcept, and tries to set them on function pointers with noexcept 
typedefs. The compiler won't like that since it'll see a 
potentially-throwing function set on a function pointer that's not 
allowed to throw when called. This can be fixed by the app adding 
noexcept to their fallback/callback functions, which they really should 
be anyway. And more generally, code written with the updated noexcept 
headers in mind will still work with non-noexcept headers.


So I'm looking for feedback. Making the functions and function pointer 
types noexcept for C++ would be beneficial, existing binaries would have 
no issues, and there's only a small possibility for fixable compile 
issues in existing code. But given that there can be issues, however 
minor, I wanted to get others' opinions before doing anything.