errno with FFI
#25507
Replies: 1 comment
-
@aapoalas can you take a look and advise? |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
An experience report from using FFI to a libc function:
Deno's filesystem API doesn't have
mkfifo
, so I went to see if I could invoke it via FFI. I found the Deno.dlopen interface straightforward to use, especially for this case where the API I'm interested in is very small and stable.The happy path worked great.
Next I went to check on the error handling. libc error handling is as cumbersome as it ever was, but I went through the motions: check the static global variable
errno
, consultstrerror()
to get something human-readable, etc… It was a bit of a chore, as surely the runtime must already have implemented this somewhere before, but I couldn't find it exposed for our use.Eventually I got it to produce an error message saying “No such file or directory [ENOENT]”. A significant improvement over “Error.”
I called my function again with different arguments to trigger a different type of error case, and— “No such file or directory” again.
🫤 … no, that's not the appropriate error message this time. What went wrong?
The thing I didn't realize is that though
libc.symbols.errno
was looking at theerrno
I intended it to, the properties of the DynamicLibrary.symbols are only set once, when it's created. It's not a live view. No matter how many errors I cause, that value is stuck at whatever it was when I first called dlopen.Deno.dlopen is capable of doing what we need here, it just took a little more rummaging with unstable interfaces with "Unsafe" in their name:
Beta Was this translation helpful? Give feedback.
All reactions