Call a function in a shared library: Difference between revisions
Content added Content deleted
(→Call uname on Linux: Explanations.) |
|||
| Line 1,401: | Line 1,401: | ||
We use <code>typedef</code> to condense the declarations, much like in C. The FFI handles nested types like arrays in structures. |
We use <code>typedef</code> to condense the declarations, much like in C. The FFI handles nested types like arrays in structures. |
||
The <code>zarray</code> type denotes null-terminated arrays. A <code>zarray</code> of < |
The <code>zarray</code> type denotes null-terminated arrays. A <code>zarray</code> of <code>char</code> is specialized; it converts between Lisp strings (which use wide characters made of Unicode code points) and C <code>char</code> strings encoded in UTF-8. |
||
The argument of <code>uname</code> is <code>(ptr-out utsname)</code>. The semantics of <code>ptr-out</code> in this situation is that FFI prepares a C version of the Lisp structure, but doesn't perform any conversions from Lisp to initialize it. This not only saves CPU cycles, but allows us to use a blank structure produced by <code>(new utsname)</code> all of whose slots are <code>nil</code> and so wouldn't convert to C character arrays anyway! The function is called, and then conversions out of the structure to the Lisp structure take place, filling its slots with string values. |
The argument of <code>uname</code> is <code>(ptr-out utsname)</code>. The semantics of <code>ptr-out</code> in this situation is that FFI prepares a C version of the Lisp structure, but doesn't perform any conversions from Lisp to initialize it. This not only saves CPU cycles, but allows us to use a blank structure produced by <code>(new utsname)</code> all of whose slots are <code>nil</code> and so wouldn't convert to C character arrays anyway! The function is called, and then conversions out of the structure to the Lisp structure take place, filling its slots with string values. |
||