jl_dlsym incorrectly assumes a NULL return is an error

[Keno]

Quoth the man page:

Since the value of the symbol could actually be NULL (so that a NULL return from dlsym() need not indicate an error), the correct way to test for an error is to call dlerror() to clear any old error conditions, then call dlsym(), and then call dlerror() again, saving its return value into a variable, and check whether this saved value is not NULL.

NULL-mapped symbols are sometimes used to indicate feature levels (e.g. in libstdc++). We should make sure to support them. One complication is that we exposed this behavior through dlsym_e. We should probably have a function that returns either a pointer value or nothing if the symbol was not found.

[staticfloat]

So as it stands now, jl_dlsym_e() does not disambiguate between failure (symbol does not exist) and success with a null result (symbol exists but points to the memory location 0x00000000). In order for this to work, we either need to, in C code, come up with a new value that means "symbol was not found" (perhaps change that to be (int_ptr)(-1) instead of NULL?), or change the semantics of jl_dlsym_e to use sidechannel outputs (e.g. bool jl_dlsym_e(void * handle, const char * symbol, void ** symbol_addr) or somesuch).

What do you guys think? Either way it's a breaking change, so let's do The Right Thing (TM). I personally like the sidechannel API look better.

[staticfloat]

Also, it looks like Windows does not support NULL-valued symbols: https://msdn.microsoft.com/en-us/library/windows/desktop/ms683212(v=vs.85).aspx

[Keno]

int_ptr)(-1)

Also a valid symbol.

We need an extra bit of information, which is why I suggested using Union{Ptr, Nothing} above. I think we can add a new API that does that and reimplement the two existing ones on top of that. dlsym is a bit easier since adding a null result is non breaking, but would probably have to deprecate dlsym_e in favor of a new API with the extra bit of information.

[staticfloat]

I think we need to first fix this at the C level, not the Julia level. Unless you’re suggesting using Julia’s C API to return a Union from jl_dlsym_e()?

[Keno]

I'm not, but we can do whatever at the C level (your suggestion is fine), we don't have stability guarantees there.