Libdl.dlopen returns a non-NULL pointer on empty string

[joshbode]

On Linux, dlopen and dlopen_e return a non-zero pointer when given an empty string.

Linux VM (on macOS) using the official 0.5.2 Linux binaries:

julia> Libdl.dlopen("")
Ptr{Void} @0x00007f183b11a1a8

julia> Libdl.dlopen_e("")
Ptr{Void} @0x00007f183b11a1a8

julia> versioninfo()
Julia Version 0.5.2
Commit f4c6c9d (2017-05-06 16:34 UTC)
Platform Info:
  OS: Linux (x86_64-pc-linux-gnu)
  CPU: Intel(R) Core(TM)2 Duo CPU     P7550  @ 2.26GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Penryn)
  LAPACK: libopenblas64_
  LIBM: libopenlibm
  LLVM: libLLVM-3.7.1 (ORCJIT, penryn)

Linux VM using the official 0.6.0-rc3 Linux binaries:

julia> Libdl.dlopen("")
Ptr{Void} @0x00007f4c365cd1a8

julia> Libdl.dlopen_e("")
Ptr{Void} @0x00007f4c365cd1a8

julia> versioninfo()
Julia Version 0.6.0-rc3.0
Commit ad290e9 (2017-06-07 11:53 UTC)
Platform Info:
  OS: Linux (x86_64-pc-linux-gnu)
  CPU: Intel(R) Core(TM)2 Duo CPU     P7550  @ 2.26GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Penryn)
  LAPACK: libopenblas64_
  LIBM: libopenlibm
  LLVM: libLLVM-3.9.1 (ORCJIT, penryn)

Same behaviour also observed natively (no VM) under Linux on a colleague's machine.

On macOS in 0.5.2 and 0.6.0-rc3 the pointer returned by Libdl.dlopen_e("") is C_NULL and Libdl.dlopen("") is an error.

[joshbode]

Or perhaps this is expected. In python:

$ python
Python 2.7.9 (default, Jun 29 2016, 13:08:31)
[GCC 4.9.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import ctypes
>>> ctypes.cdll.LoadLibrary("")
<CDLL '', handle 7f70f29db1a8 at 7f70f287ef10>

[joshbode]

Actually, this looks right. From man 3 dlopen (Linux):

If filename is NULL, then the returned handle is for the main program.

[StefanKarpinski]

I don't think this is correct: filename == NULL is not the same as filename == "". This should be an error for the empty string (or any other string that isn't the name of a library) and should require an argument of C_NULL to give the handle of the main program.

[joshbode]

Ahh - understood.

julia> ccall(:jl_load_dynamic_library, Ptr{Void}, (Cstring, UInt32), "", Libdl.RTLD_LAZY | Libdl.RTLD_DEEPBIND)
Ptr{Void} @0x00007efd29dd71a8

julia> ccall(:jl_load_dynamic_library, Ptr{Void}, (Cstring, UInt32), C_NULL, Libdl.RTLD_LAZY | Libdl.RTLD_DEEPBIND)
Ptr{Void} @0x00007efd29dd71a8

[yuyichao]

Given that there isn't a better meaning for empty string and python does the same for it I think what we are doing is fine. It's also very strange to accept either string or null pointer. We don't have to mirror dlopen to that level. It doesn't seem to be documented though so I think it should and this can be left open as a doc issue.

[StefanKarpinski]

There certainly is a better meaning: the user passed the empty string by accident, in which case raising an error is the correct behavior. Using the empty string as an exceptional value does not strike me as better than using a different type to request a fundamentally different behavior.

[yuyichao]

Use a different type is OK. C_NULL would be the worst choise though. It'll be strange if we only allow null pointer but not other pointer and we should definitely not allow passoing C pointer to string.

It's also not as fundamentally different a behavior as you stated. If you query the info about loaded ELF files (on linux at least and likely other platforms using ELF like freebsd) with dl_iterate_phdr, the name for the executable is indeed an empty string and that's exactly what this function does. Also note that this is a dlopen behavior (i.e. dlopen returns the executable handle when passed a empty string) and not what we do so it'll be very surprinsing for C users if we patch this to an error.

[StefanKarpinski]

the name for the executable is indeed an empty string

Ok, that certainly makes this behavior much more defensible. I guess I don't really care that strongly about this.

[simonbyrne]

I think the bigger issue is that the behaviour is inconsistent: On MacOS:

julia> using Libdl

julia> dlopen("")
ERROR: could not load library ""
dlopen(.dylib, 1): image not found
Stacktrace:
 [1] #dlopen#3(::Bool, ::typeof(dlopen), ::String, ::UInt32) at /Users/sabae/buildbot/worker/package_macos64/build/usr/share/julia/stdlib/v1.3/Libdl/src/Libdl.jl:109
 [2] dlopen at /Users/sabae/buildbot/worker/package_macos64/build/usr/share/julia/stdlib/v1.3/Libdl/src/Libdl.jl:109 [inlined] (repeats 2 times)
 [3] top-level scope at REPL[2]:1

The problem is that this gives inconsistent behaviour of dlpath
(cross ref JuliaParallel/MPI.jl#334)