Commit | Line | Data |
---|---|---|
726b8ba3 AW |
1 | @c -*-texinfo-*- |
2 | @c This is part of the GNU Guile Reference Manual. | |
1f4f7674 | 3 | @c Copyright (C) 1996, 1997, 2000, 2001, 2002, 2003, 2004, 2007, 2008, |
aed9483b | 4 | @c 2009, 2010, 2011, 2012 Free Software Foundation, Inc. |
726b8ba3 AW |
5 | @c See the file guile.texi for copying conditions. |
6 | ||
726b8ba3 AW |
7 | @node Foreign Function Interface |
8 | @section Foreign Function Interface | |
9 | @cindex foreign function interface | |
10 | @cindex ffi | |
11 | ||
12 | The more one hacks in Scheme, the more one realizes that there are | |
13 | actually two computational worlds: one which is warm and alive, that | |
14 | land of parentheses, and one cold and dead, the land of C and its ilk. | |
15 | ||
16 | But yet we as programmers live in both worlds, and Guile itself is half | |
17 | implemented in C. So it is that Guile's living half pays respect to its | |
18 | dead counterpart, via a spectrum of interfaces to C ranging from dynamic | |
19 | loading of Scheme primitives to dynamic binding of stock C library | |
0b9bdb1b | 20 | procedures. |
726b8ba3 AW |
21 | |
22 | @menu | |
23 | * Foreign Libraries:: Dynamically linking to libraries. | |
24 | * Foreign Functions:: Simple calls to C procedures. | |
25 | * C Extensions:: Extending Guile in C with loadable modules. | |
26 | * Modules and Extensions:: Loading C extensions into modules. | |
71725997 AW |
27 | * Foreign Pointers:: Accessing global variables. |
28 | * Dynamic FFI:: Calling arbitrary C functions. | |
726b8ba3 AW |
29 | @end menu |
30 | ||
31 | ||
32 | @node Foreign Libraries | |
33 | @subsection Foreign Libraries | |
34 | ||
35 | Most modern Unices have something called @dfn{shared libraries}. This | |
36 | ordinarily means that they have the capability to share the executable | |
37 | image of a library between several running programs to save memory and | |
38 | disk space. But generally, shared libraries give a lot of additional | |
39 | flexibility compared to the traditional static libraries. In fact, | |
40 | calling them `dynamic' libraries is as correct as calling them `shared'. | |
41 | ||
42 | Shared libraries really give you a lot of flexibility in addition to the | |
43 | memory and disk space savings. When you link a program against a shared | |
44 | library, that library is not closely incorporated into the final | |
45 | executable. Instead, the executable of your program only contains | |
46 | enough information to find the needed shared libraries when the program | |
47 | is actually run. Only then, when the program is starting, is the final | |
48 | step of the linking process performed. This means that you need not | |
49 | recompile all programs when you install a new, only slightly modified | |
50 | version of a shared library. The programs will pick up the changes | |
51 | automatically the next time they are run. | |
52 | ||
53 | Now, when all the necessary machinery is there to perform part of the | |
54 | linking at run-time, why not take the next step and allow the programmer | |
55 | to explicitly take advantage of it from within his program? Of course, | |
56 | many operating systems that support shared libraries do just that, and | |
57 | chances are that Guile will allow you to access this feature from within | |
58 | your Scheme programs. As you might have guessed already, this feature | |
59 | is called @dfn{dynamic linking}.@footnote{Some people also refer to the | |
60 | final linking stage at program startup as `dynamic linking', so if you | |
61 | want to make yourself perfectly clear, it is probably best to use the | |
62 | more technical term @dfn{dlopening}, as suggested by Gordon Matzigkeit | |
63 | in his libtool documentation.} | |
64 | ||
65 | We titled this section ``foreign libraries'' because although the name | |
66 | ``foreign'' doesn't leak into the API, the world of C really is foreign | |
67 | to Scheme -- and that estrangement extends to components of foreign | |
68 | libraries as well, as we see in future sections. | |
69 | ||
70 | @deffn {Scheme Procedure} dynamic-link [library] | |
71 | @deffnx {C Function} scm_dynamic_link (library) | |
72 | Find the shared library denoted by @var{library} (a string) and link it | |
73 | into the running Guile application. When everything works out, return a | |
74 | Scheme object suitable for representing the linked object file. | |
75 | Otherwise an error is thrown. How object files are searched is system | |
76 | dependent. | |
77 | ||
78 | Normally, @var{library} is just the name of some shared library file | |
79 | that will be searched for in the places where shared libraries usually | |
80 | reside, such as in @file{/usr/lib} and @file{/usr/local/lib}. | |
81 | ||
fba502db LC |
82 | @var{library} should not contain an extension such as @code{.so}. The |
83 | correct file name extension for the host operating system is provided | |
84 | automatically, according to libltdl's rules (@pxref{Libltdl interface, | |
85 | lt_dlopenext, @code{lt_dlopenext}, libtool, Shared Library Support for | |
86 | GNU}). | |
87 | ||
726b8ba3 AW |
88 | When @var{library} is omitted, a @dfn{global symbol handle} is returned. This |
89 | handle provides access to the symbols available to the program at run-time, | |
90 | including those exported by the program itself and the shared libraries already | |
91 | loaded. | |
92 | @end deffn | |
93 | ||
94 | @deffn {Scheme Procedure} dynamic-object? obj | |
95 | @deffnx {C Function} scm_dynamic_object_p (obj) | |
96 | Return @code{#t} if @var{obj} is a dynamic library handle, or @code{#f} | |
97 | otherwise. | |
98 | @end deffn | |
99 | ||
100 | @deffn {Scheme Procedure} dynamic-unlink dobj | |
101 | @deffnx {C Function} scm_dynamic_unlink (dobj) | |
102 | Unlink the indicated object file from the application. The | |
103 | argument @var{dobj} must have been obtained by a call to | |
104 | @code{dynamic-link}. After @code{dynamic-unlink} has been | |
105 | called on @var{dobj}, its content is no longer accessible. | |
106 | @end deffn | |
107 | ||
108 | @smallexample | |
71725997 AW |
109 | (define libgl-obj (dynamic-link "libGL")) |
110 | libgl-obj | |
111 | @result{} #<dynamic-object "libGL"> | |
112 | (dynamic-unlink libGL-obj) | |
113 | libGL-obj | |
114 | @result{} #<dynamic-object "libGL" (unlinked)> | |
726b8ba3 AW |
115 | @end smallexample |
116 | ||
117 | As you can see, after calling @code{dynamic-unlink} on a dynamically | |
118 | linked library, it is marked as @samp{(unlinked)} and you are no longer | |
119 | able to use it with @code{dynamic-call}, etc. Whether the library is | |
120 | really removed from you program is system-dependent and will generally | |
71725997 | 121 | not happen when some other parts of your program still use it. |
726b8ba3 AW |
122 | |
123 | When dynamic linking is disabled or not supported on your system, | |
124 | the above functions throw errors, but they are still available. | |
125 | ||
126 | ||
127 | @node Foreign Functions | |
128 | @subsection Foreign Functions | |
129 | ||
43cd9cec AW |
130 | The most natural thing to do with a dynamic library is to grovel around |
131 | in it for a function pointer: a @dfn{foreign function}. | |
132 | @code{dynamic-func} exists for that purpose. | |
133 | ||
726b8ba3 AW |
134 | @deffn {Scheme Procedure} dynamic-func name dobj |
135 | @deffnx {C Function} scm_dynamic_func (name, dobj) | |
136 | Return a ``handle'' for the func @var{name} in the shared object referred to | |
137 | by @var{dobj}. The handle can be passed to @code{dynamic-call} to | |
138 | actually call the function. | |
139 | ||
140 | Regardless whether your C compiler prepends an underscore @samp{_} to the global | |
141 | names in a program, you should @strong{not} include this underscore in | |
142 | @var{name} since it will be added automatically when necessary. | |
143 | @end deffn | |
144 | ||
43cd9cec AW |
145 | Guile has static support for calling functions with no arguments, |
146 | @code{dynamic-call}. | |
147 | ||
726b8ba3 AW |
148 | @deffn {Scheme Procedure} dynamic-call func dobj |
149 | @deffnx {C Function} scm_dynamic_call (func, dobj) | |
150 | Call the C function indicated by @var{func} and @var{dobj}. | |
151 | The function is passed no arguments and its return value is | |
152 | ignored. When @var{function} is something returned by | |
153 | @code{dynamic-func}, call that function and ignore @var{dobj}. | |
154 | When @var{func} is a string , look it up in @var{dynobj}; this | |
155 | is equivalent to | |
156 | @smallexample | |
157 | (dynamic-call (dynamic-func @var{func} @var{dobj}) #f) | |
158 | @end smallexample | |
159 | ||
160 | Interrupts are deferred while the C function is executing (with | |
161 | @code{SCM_DEFER_INTS}/@code{SCM_ALLOW_INTS}). | |
162 | @end deffn | |
163 | ||
43cd9cec AW |
164 | @code{dynamic-call} is not very powerful. It is mostly intended to be |
165 | used for calling specially written initialization functions that will | |
166 | then add new primitives to Guile. For example, we do not expect that you | |
167 | will dynamically link @file{libX11} with @code{dynamic-link} and then | |
168 | construct a beautiful graphical user interface just by using | |
169 | @code{dynamic-call}. Instead, the usual way would be to write a special | |
71725997 | 170 | Guile-to-X11 glue library that has intimate knowledge about both Guile |
43cd9cec AW |
171 | and X11 and does whatever is necessary to make them inter-operate |
172 | smoothly. This glue library could then be dynamically linked into a | |
726b8ba3 | 173 | vanilla Guile interpreter and activated by calling its initialization |
43cd9cec | 174 | function. That function would add all the new types and primitives to |
726b8ba3 AW |
175 | the Guile interpreter that it has to offer. |
176 | ||
43cd9cec AW |
177 | (There is actually another, better option: simply to create a |
178 | @file{libX11} wrapper in Scheme via the dynamic FFI. @xref{Dynamic FFI}, | |
179 | for more information.) | |
726b8ba3 | 180 | |
43cd9cec AW |
181 | Given some set of C extensions to Guile, the next logical step is to |
182 | integrate these glue libraries into the module system of Guile so that | |
183 | you can load new primitives into a running system just as you can load | |
184 | new Scheme code. | |
726b8ba3 AW |
185 | |
186 | @deffn {Scheme Procedure} load-extension lib init | |
187 | @deffnx {C Function} scm_load_extension (lib, init) | |
188 | Load and initialize the extension designated by LIB and INIT. | |
189 | When there is no pre-registered function for LIB/INIT, this is | |
190 | equivalent to | |
191 | ||
192 | @lisp | |
193 | (dynamic-call INIT (dynamic-link LIB)) | |
194 | @end lisp | |
195 | ||
196 | When there is a pre-registered function, that function is called | |
197 | instead. | |
198 | ||
199 | Normally, there is no pre-registered function. This option exists | |
200 | only for situations where dynamic linking is unavailable or unwanted. | |
201 | In that case, you would statically link your program with the desired | |
202 | library, and register its init function right after Guile has been | |
203 | initialized. | |
204 | ||
fba502db LC |
205 | As for @code{dynamic-link}, @var{lib} should not contain any suffix such |
206 | as @code{.so} (@pxref{Foreign Libraries, dynamic-link}). It | |
726b8ba3 AW |
207 | should also not contain any directory components. Libraries that |
208 | implement Guile Extensions should be put into the normal locations for | |
209 | shared libraries. We recommend to use the naming convention | |
fba502db LC |
210 | @file{libguile-bla-blum} for a extension related to a module @code{(bla |
211 | blum)}. | |
726b8ba3 AW |
212 | |
213 | The normal way for a extension to be used is to write a small Scheme | |
214 | file that defines a module, and to load the extension into this | |
215 | module. When the module is auto-loaded, the extension is loaded as | |
216 | well. For example, | |
217 | ||
218 | @lisp | |
219 | (define-module (bla blum)) | |
220 | ||
221 | (load-extension "libguile-bla-blum" "bla_init_blum") | |
222 | @end lisp | |
223 | @end deffn | |
224 | ||
225 | @node C Extensions | |
226 | @subsection C Extensions | |
227 | ||
228 | The most interesting application of dynamically linked libraries is | |
229 | probably to use them for providing @emph{compiled code modules} to | |
230 | Scheme programs. As much fun as programming in Scheme is, every now and | |
231 | then comes the need to write some low-level C stuff to make Scheme even | |
232 | more fun. | |
233 | ||
234 | Not only can you put these new primitives into their own module (see the | |
235 | previous section), you can even put them into a shared library that is | |
236 | only then linked to your running Guile image when it is actually | |
237 | needed. | |
238 | ||
239 | An example will hopefully make everything clear. Suppose we want to | |
240 | make the Bessel functions of the C library available to Scheme in the | |
241 | module @samp{(math bessel)}. First we need to write the appropriate | |
242 | glue code to convert the arguments and return values of the functions | |
243 | from Scheme to C and back. Additionally, we need a function that will | |
244 | add them to the set of Guile primitives. Because this is just an | |
245 | example, we will only implement this for the @code{j0} function. | |
246 | ||
247 | @smallexample | |
248 | #include <math.h> | |
249 | #include <libguile.h> | |
250 | ||
251 | SCM | |
252 | j0_wrapper (SCM x) | |
253 | @{ | |
254 | return scm_from_double (j0 (scm_to_double (x, "j0"))); | |
255 | @} | |
256 | ||
257 | void | |
258 | init_math_bessel () | |
259 | @{ | |
260 | scm_c_define_gsubr ("j0", 1, 0, 0, j0_wrapper); | |
261 | @} | |
262 | @end smallexample | |
263 | ||
264 | We can already try to bring this into action by manually calling the low | |
265 | level functions for performing dynamic linking. The C source file needs | |
266 | to be compiled into a shared library. Here is how to do it on | |
267 | GNU/Linux, please refer to the @code{libtool} documentation for how to | |
268 | create dynamically linkable libraries portably. | |
269 | ||
270 | @smallexample | |
271 | gcc -shared -o libbessel.so -fPIC bessel.c | |
272 | @end smallexample | |
273 | ||
274 | Now fire up Guile: | |
275 | ||
276 | @lisp | |
277 | (define bessel-lib (dynamic-link "./libbessel.so")) | |
278 | (dynamic-call "init_math_bessel" bessel-lib) | |
279 | (j0 2) | |
280 | @result{} 0.223890779141236 | |
281 | @end lisp | |
282 | ||
283 | The filename @file{./libbessel.so} should be pointing to the shared | |
284 | library produced with the @code{gcc} command above, of course. The | |
285 | second line of the Guile interaction will call the | |
286 | @code{init_math_bessel} function which in turn will register the C | |
287 | function @code{j0_wrapper} with the Guile interpreter under the name | |
288 | @code{j0}. This function becomes immediately available and we can call | |
289 | it from Scheme. | |
290 | ||
291 | Fun, isn't it? But we are only half way there. This is what | |
292 | @code{apropos} has to say about @code{j0}: | |
293 | ||
294 | @smallexample | |
295 | (apropos "j0") | |
296 | @print{} (guile-user): j0 #<primitive-procedure j0> | |
297 | @end smallexample | |
298 | ||
299 | As you can see, @code{j0} is contained in the root module, where all | |
300 | the other Guile primitives like @code{display}, etc live. In general, | |
301 | a primitive is put into whatever module is the @dfn{current module} at | |
302 | the time @code{scm_c_define_gsubr} is called. | |
303 | ||
304 | A compiled module should have a specially named @dfn{module init | |
305 | function}. Guile knows about this special name and will call that | |
306 | function automatically after having linked in the shared library. For | |
307 | our example, we replace @code{init_math_bessel} with the following code in | |
308 | @file{bessel.c}: | |
309 | ||
310 | @smallexample | |
311 | void | |
312 | init_math_bessel (void *unused) | |
313 | @{ | |
314 | scm_c_define_gsubr ("j0", 1, 0, 0, j0_wrapper); | |
315 | scm_c_export ("j0", NULL); | |
316 | @} | |
317 | ||
318 | void | |
319 | scm_init_math_bessel_module () | |
320 | @{ | |
321 | scm_c_define_module ("math bessel", init_math_bessel, NULL); | |
322 | @} | |
323 | @end smallexample | |
324 | ||
325 | The general pattern for the name of a module init function is: | |
326 | @samp{scm_init_}, followed by the name of the module where the | |
327 | individual hierarchical components are concatenated with underscores, | |
328 | followed by @samp{_module}. | |
329 | ||
330 | After @file{libbessel.so} has been rebuilt, we need to place the shared | |
331 | library into the right place. | |
332 | ||
333 | Once the module has been correctly installed, it should be possible to | |
334 | use it like this: | |
335 | ||
336 | @smallexample | |
337 | guile> (load-extension "./libbessel.so" "scm_init_math_bessel_module") | |
338 | guile> (use-modules (math bessel)) | |
339 | guile> (j0 2) | |
340 | 0.223890779141236 | |
341 | guile> (apropos "j0") | |
342 | @print{} (math bessel): j0 #<primitive-procedure j0> | |
343 | @end smallexample | |
344 | ||
345 | That's it! | |
346 | ||
726b8ba3 AW |
347 | |
348 | @node Modules and Extensions | |
349 | @subsection Modules and Extensions | |
350 | ||
351 | The new primitives that you add to Guile with @code{scm_c_define_gsubr} | |
352 | (@pxref{Primitive Procedures}) or with any of the other mechanisms are | |
353 | placed into the module that is current when the | |
354 | @code{scm_c_define_gsubr} is executed. Extensions loaded from the REPL, | |
355 | for example, will be placed into the @code{(guile-user)} module, if the | |
356 | REPL module was not changed. | |
357 | ||
358 | To define C primitives within a specific module, the simplest way is: | |
359 | ||
360 | @example | |
361 | (define-module (foo bar)) | |
362 | (load-extension "foobar-c-code" "foo_bar_init") | |
363 | @end example | |
364 | ||
e5f7f675 | 365 | @cindex extensiondir |
726b8ba3 AW |
366 | When loaded with @code{(use-modules (foo bar))}, the |
367 | @code{load-extension} call looks for the @file{foobar-c-code.so} (etc) | |
e5f7f675 AW |
368 | object file in Guile's @code{extensiondir}, which is usually a |
369 | subdirectory of the @code{libdir}. For example, if your libdir is | |
4b93693d AW |
370 | @file{/usr/lib}, the @code{extensiondir} for the Guile @value{EFFECTIVE-VERSION}.@var{x} |
371 | series will be @file{/usr/lib/guile/@value{EFFECTIVE-VERSION}/}. | |
e5f7f675 AW |
372 | |
373 | The extension path includes the major and minor version of Guile (the | |
374 | ``effective version''), because Guile guarantees compatibility within a | |
375 | given effective version. This allows you to install different versions | |
376 | of the same extension for different versions of Guile. | |
377 | ||
378 | If the extension is not found in the @code{extensiondir}, Guile will | |
379 | also search the standard system locations, such as @file{/usr/lib} or | |
380 | @file{/usr/local/lib}. It is preferable, however, to keep your extension | |
381 | out of the system library path, to prevent unintended interference with | |
382 | other dynamically-linked C libraries. | |
726b8ba3 AW |
383 | |
384 | If someone installs your module to a non-standard location then the | |
385 | object file won't be found. You can address this by inserting the | |
386 | install location in the @file{foo/bar.scm} file. This is convenient | |
387 | for the user and also guarantees the intended object is read, even if | |
388 | stray older or newer versions are in the loader's path. | |
389 | ||
390 | The usual way to specify an install location is with a @code{prefix} | |
391 | at the configure stage, for instance @samp{./configure prefix=/opt} | |
392 | results in library files as say @file{/opt/lib/foobar-c-code.so}. | |
393 | When using Autoconf (@pxref{Top, , Introduction, autoconf, The GNU | |
394 | Autoconf Manual}), the library location is in a @code{libdir} | |
395 | variable. Its value is intended to be expanded by @command{make}, and | |
396 | can by substituted into a source file like @file{foo.scm.in} | |
397 | ||
398 | @example | |
399 | (define-module (foo bar)) | |
e5f7f675 | 400 | (load-extension "XXextensiondirXX/foobar-c-code" "foo_bar_init") |
726b8ba3 AW |
401 | @end example |
402 | ||
403 | @noindent | |
404 | with the following in a @file{Makefile}, using @command{sed} | |
405 | (@pxref{Top, , Introduction, sed, SED, A Stream Editor}), | |
406 | ||
407 | @example | |
408 | foo.scm: foo.scm.in | |
4b93693d | 409 | sed 's|XXextensiondirXX|$(libdir)/guile/@value{EFFECTIVE-VERSION}|' <foo.scm.in >foo.scm |
726b8ba3 AW |
410 | @end example |
411 | ||
e5f7f675 | 412 | The actual pattern @code{XXextensiondirXX} is arbitrary, it's only something |
726b8ba3 AW |
413 | which doesn't otherwise occur. If several modules need the value, it |
414 | can be easier to create one @file{foo/config.scm} with a define of the | |
e5f7f675 | 415 | @code{extensiondir} location, and use that as required. |
726b8ba3 AW |
416 | |
417 | @example | |
418 | (define-module (foo config)) | |
e5f7f675 | 419 | (define-public foo-config-extensiondir "XXextensiondirXX"") |
726b8ba3 AW |
420 | @end example |
421 | ||
422 | Such a file might have other locations too, for instance a data | |
423 | directory for auxiliary files, or @code{localedir} if the module has | |
424 | its own @code{gettext} message catalogue | |
425 | (@pxref{Internationalization}). | |
426 | ||
726b8ba3 | 427 | It will be noted all of the above requires that the Scheme code to be |
0740cb49 AW |
428 | found in @code{%load-path} (@pxref{Load Paths}). Presently it's left up |
429 | to the system administrator or each user to augment that path when | |
430 | installing Guile modules in non-default locations. But having reached | |
431 | the Scheme code, that code should take care of hitting any of its own | |
432 | private files etc. | |
726b8ba3 | 433 | |
726b8ba3 | 434 | |
71725997 AW |
435 | @node Foreign Pointers |
436 | @subsection Foreign Pointers | |
437 | ||
438 | The previous sections have shown how Guile can be extended at runtime by | |
439 | loading compiled C extensions. This approach is all well and good, but | |
440 | wouldn't it be nice if we didn't have to write any C at all? This | |
441 | section takes up the problem of accessing C values from Scheme, and the | |
442 | next discusses C functions. | |
443 | ||
444 | @menu | |
b9264dc5 | 445 | * Foreign Types:: Expressing C types in Scheme. |
183a2a22 | 446 | * Foreign Variables:: Pointers to C symbols. |
b9264dc5 AW |
447 | * Void Pointers and Byte Access:: Pointers into the ether. |
448 | * Foreign Structs:: Packing and unpacking structs. | |
71725997 AW |
449 | @end menu |
450 | ||
451 | @node Foreign Types | |
452 | @subsubsection Foreign Types | |
453 | ||
454 | The first impedance mismatch that one sees between C and Scheme is that | |
455 | in C, the storage locations (variables) are typed, but in Scheme types | |
456 | are associated with values, not variables. @xref{Values and Variables}. | |
457 | ||
183a2a22 LC |
458 | So when describing a C function or a C structure so that it can be |
459 | accessed from Scheme, the data types of the parameters or fields must be | |
460 | passed explicitly. | |
71725997 AW |
461 | |
462 | These ``C type values'' may be constructed using the constants and | |
463 | procedures from the @code{(system foreign)} module, which may be loaded | |
464 | like this: | |
465 | ||
466 | @example | |
467 | (use-modules (system foreign)) | |
468 | @end example | |
469 | ||
470 | @code{(system foreign)} exports a number of values expressing the basic | |
471 | C types: | |
472 | ||
b9264dc5 | 473 | @defvr {Scheme Variable} int8 |
71725997 AW |
474 | @defvrx {Scheme Variable} uint8 |
475 | @defvrx {Scheme Variable} uint16 | |
476 | @defvrx {Scheme Variable} int16 | |
477 | @defvrx {Scheme Variable} uint32 | |
478 | @defvrx {Scheme Variable} int32 | |
479 | @defvrx {Scheme Variable} uint64 | |
480 | @defvrx {Scheme Variable} int64 | |
b9264dc5 AW |
481 | @defvrx {Scheme Variable} float |
482 | @defvrx {Scheme Variable} double | |
183a2a22 LC |
483 | These values represent the C numeric types of the specified sizes and |
484 | signednesses. | |
71725997 AW |
485 | @end defvr |
486 | ||
487 | In addition there are some convenience bindings for indicating types of | |
488 | platform-dependent size: | |
489 | ||
490 | @defvr {Scheme Variable} int | |
491 | @defvrx {Scheme Variable} unsigned-int | |
492 | @defvrx {Scheme Variable} long | |
493 | @defvrx {Scheme Variable} unsigned-long | |
494 | @defvrx {Scheme Variable} size_t | |
495 | Values exported by the @code{(system foreign)} module, representing C | |
496 | numeric types. For example, @code{long} may be @code{equal?} to | |
497 | @code{int64} on a 64-bit platform. | |
498 | @end defvr | |
499 | ||
183a2a22 LC |
500 | @defvr {Scheme Variable} void |
501 | The @code{void} type. It can be used as the first argument to | |
2ee07358 | 502 | @code{pointer->procedure} to wrap a C function that returns nothing. |
183a2a22 LC |
503 | @end defvr |
504 | ||
1f4f7674 LC |
505 | In addition, the symbol @code{*} is used by convention to denote pointer |
506 | types. Procedures detailed in the following sections, such as | |
507 | @code{pointer->procedure}, accept it as a type descriptor. | |
508 | ||
71725997 AW |
509 | @node Foreign Variables |
510 | @subsubsection Foreign Variables | |
511 | ||
e5f7f675 AW |
512 | Pointers to variables in the current address space may be looked up |
513 | dynamically using @code{dynamic-pointer}. | |
726b8ba3 | 514 | |
183a2a22 LC |
515 | @deffn {Scheme Procedure} dynamic-pointer name dobj |
516 | @deffnx {C Function} scm_dynamic_pointer (name, dobj) | |
517 | Return a ``wrapped pointer'' for the symbol @var{name} in the shared | |
518 | object referred to by @var{dobj}. The returned pointer points to a C | |
519 | object. | |
726b8ba3 | 520 | |
726b8ba3 AW |
521 | Regardless whether your C compiler prepends an underscore @samp{_} to the global |
522 | names in a program, you should @strong{not} include this underscore in | |
523 | @var{name} since it will be added automatically when necessary. | |
524 | @end deffn | |
525 | ||
71725997 AW |
526 | For example, currently Guile has a variable, @code{scm_numptob}, as part |
527 | of its API. It is declared as a C @code{long}. So, to create a handle | |
528 | pointing to that foreign value, we do: | |
529 | ||
530 | @example | |
531 | (use-modules (system foreign)) | |
183a2a22 | 532 | (define numptob (dynamic-pointer "scm_numptob" (dynamic-link))) |
71725997 | 533 | numptob |
e5f7f675 | 534 | @result{} #<pointer 0x7fb35b1b4688> |
71725997 AW |
535 | @end example |
536 | ||
e5f7f675 AW |
537 | (The next section discusses ways to dereference pointers.) |
538 | ||
b9264dc5 | 539 | A value returned by @code{dynamic-pointer} is a Scheme wrapper for a C |
183a2a22 | 540 | pointer. |
b9264dc5 | 541 | |
183a2a22 | 542 | @deffn {Scheme Procedure} pointer-address pointer |
5f6ffd66 | 543 | @deffnx {C Function} scm_pointer_address (pointer) |
183a2a22 | 544 | Return the numerical value of @var{pointer}. |
b9264dc5 AW |
545 | |
546 | @example | |
183a2a22 LC |
547 | (pointer-address numptob) |
548 | @result{} 139984413364296 ; YMMV | |
b9264dc5 AW |
549 | @end example |
550 | @end deffn | |
551 | ||
183a2a22 LC |
552 | @deffn {Scheme Procedure} make-pointer address [finalizer] |
553 | Return a foreign pointer object pointing to @var{address}. If | |
554 | @var{finalizer} is passed, it should be a pointer to a one-argument C | |
555 | function that will be called when the pointer object becomes | |
556 | unreachable. | |
557 | @end deffn | |
b9264dc5 | 558 | |
6e097560 LC |
559 | @deffn {Scheme Procedure} pointer? obj |
560 | Return @code{#t} if @var{obj} is a pointer object, @code{#f} otherwise. | |
561 | @end deffn | |
562 | ||
183a2a22 LC |
563 | @defvr {Scheme Variable} %null-pointer |
564 | A foreign pointer whose value is 0. | |
565 | @end defvr | |
b9264dc5 | 566 | |
183a2a22 LC |
567 | @deffn {Scheme Procedure} null-pointer? pointer |
568 | Return @code{#t} if @var{pointer} is the null pointer, @code{#f} otherwise. | |
b9264dc5 AW |
569 | @end deffn |
570 | ||
148c3317 AW |
571 | For the purpose of passing SCM values directly to foreign functions, and |
572 | allowing them to return SCM values, Guile also supports some unsafe | |
573 | casting operators. | |
574 | ||
575 | @deffn {Scheme Procedure} scm->pointer scm | |
576 | Return a foreign pointer object with the @code{object-address} | |
577 | of @var{scm}. | |
578 | @end deffn | |
579 | ||
580 | @deffn {Scheme Procedure} pointer->scm pointer | |
581 | Unsafely cast @var{pointer} to a Scheme object. | |
582 | Cross your fingers! | |
583 | @end deffn | |
584 | ||
467be245 AW |
585 | Sometimes you want to give C extensions access to the dynamic FFI. At |
586 | that point, the names get confusing, because ``pointer'' can refer to a | |
587 | @code{SCM} object that wraps a pointer, or to a @code{void*} value. We | |
588 | will try to use ``pointer object'' to refer to Scheme objects, and | |
589 | ``pointer value'' to refer to @code{void *} values. | |
590 | ||
591 | @deftypefn {C Function} SCM scm_from_pointer (void *ptr, void (*finalizer) (void*)) | |
592 | Create a pointer object from a pointer value. | |
593 | ||
594 | If @var{finalizer} is non-null, Guile arranges to call it on the pointer | |
595 | value at some point after the pointer object becomes collectable. | |
596 | @end deftypefn | |
597 | ||
598 | @deftypefn {C Function} void* scm_to_pointer (SCM obj) | |
599 | Unpack the pointer value from a pointer object. | |
600 | @end deftypefn | |
b9264dc5 AW |
601 | |
602 | @node Void Pointers and Byte Access | |
603 | @subsubsection Void Pointers and Byte Access | |
604 | ||
183a2a22 LC |
605 | Wrapped pointers are untyped, so they are essentially equivalent to C |
606 | @code{void} pointers. As in C, the memory region pointed to by a | |
607 | pointer can be accessed at the byte level. This is achieved using | |
608 | @emph{bytevectors} (@pxref{Bytevectors}). The @code{(rnrs bytevector)} | |
609 | module contains procedures that can be used to convert byte sequences to | |
e5f7f675 | 610 | Scheme objects such as strings, floating point numbers, or integers. |
71725997 | 611 | |
183a2a22 | 612 | @deffn {Scheme Procedure} pointer->bytevector pointer len [offset [uvec_type]] |
7cc8ef62 | 613 | @deffnx {C Function} scm_pointer_to_bytevector (pointer, len, offset, uvec_type) |
183a2a22 LC |
614 | Return a bytevector aliasing the @var{len} bytes pointed to by |
615 | @var{pointer}. | |
71725997 AW |
616 | |
617 | The user may specify an alternate default interpretation for | |
618 | the memory by passing the @var{uvec_type} argument, to indicate | |
619 | that the memory is an array of elements of that type. | |
620 | @var{uvec_type} should be something that | |
621 | @code{uniform-vector-element-type} would return, like @code{f32} | |
622 | or @code{s16}. | |
623 | ||
183a2a22 LC |
624 | When @var{offset} is passed, it specifies the offset in bytes relative |
625 | to @var{pointer} of the memory region aliased by the returned | |
626 | bytevector. | |
71725997 AW |
627 | |
628 | Mutating the returned bytevector mutates the memory pointed to by | |
183a2a22 | 629 | @var{pointer}, so buckle your seatbelts. |
71725997 AW |
630 | @end deffn |
631 | ||
183a2a22 | 632 | @deffn {Scheme Procedure} bytevector->pointer bv [offset] |
5f6ffd66 | 633 | @deffnx {C Function} scm_bytevector_to_pointer (bv, offset) |
183a2a22 LC |
634 | Return a pointer pointer aliasing the memory pointed to by @var{bv} or |
635 | @var{offset} bytes after @var{bv} when @var{offset} is passed. | |
636 | @end deffn | |
71725997 | 637 | |
183a2a22 | 638 | In addition to these primitives, convenience procedures are available: |
b9264dc5 | 639 | |
183a2a22 LC |
640 | @deffn {Scheme Procedure} dereference-pointer pointer |
641 | Assuming @var{pointer} points to a memory region that holds a pointer, | |
642 | return this pointer. | |
71725997 AW |
643 | @end deffn |
644 | ||
c6b08d21 | 645 | @deffn {Scheme Procedure} string->pointer string [encoding] |
fa2a89a6 | 646 | Return a foreign pointer to a nul-terminated copy of @var{string} in the |
c6b08d21 AW |
647 | given @var{encoding}, defaulting to the current locale encoding. The C |
648 | string is freed when the returned foreign pointer becomes unreachable. | |
fa2a89a6 | 649 | |
c6b08d21 | 650 | This is the Scheme equivalent of @code{scm_to_stringn}. |
fa2a89a6 LC |
651 | @end deffn |
652 | ||
c6b08d21 AW |
653 | @deffn {Scheme Procedure} pointer->string pointer [length] [encoding] |
654 | Return the string representing the C string pointed to by @var{pointer}. | |
655 | If @var{length} is omitted or @code{-1}, the string is assumed to be | |
656 | nul-terminated. Otherwise @var{length} is the number of bytes in memory | |
657 | pointed to by @var{pointer}. The C string is assumed to be in the given | |
658 | @var{encoding}, defaulting to the current locale encoding. | |
fa2a89a6 | 659 | |
c6b08d21 | 660 | This is the Scheme equivalent of @code{scm_from_stringn}. |
fa2a89a6 LC |
661 | @end deffn |
662 | ||
1f4f7674 LC |
663 | @cindex wrapped pointer types |
664 | Most object-oriented C libraries use pointers to specific data | |
665 | structures to identify objects. It is useful in such cases to reify the | |
666 | different pointer types as disjoint Scheme types. The | |
667 | @code{define-wrapped-pointer-type} macro simplifies this. | |
668 | ||
de6fb187 | 669 | @deffn {Scheme Syntax} define-wrapped-pointer-type type-name pred wrap unwrap print |
1f4f7674 LC |
670 | Define helper procedures to wrap pointer objects into Scheme objects |
671 | with a disjoint type. Specifically, this macro defines: | |
672 | ||
673 | @itemize | |
674 | @item @var{pred}, a predicate for the new Scheme type; | |
675 | @item @var{wrap}, a procedure that takes a pointer object and returns an | |
676 | object that satisfies @var{pred}; | |
677 | @item @var{unwrap}, which does the reverse. | |
678 | @end itemize | |
679 | ||
680 | @var{wrap} preserves pointer identity, for two pointer objects @var{p1} | |
681 | and @var{p2} that are @code{equal?}, @code{(eq? (@var{wrap} @var{p1}) | |
682 | (@var{wrap} @var{p2})) @result{} #t}. | |
683 | ||
684 | Finally, @var{print} should name a user-defined procedure to print such | |
685 | objects. The procedure is passed the wrapped object and a port to write | |
686 | to. | |
687 | ||
688 | For example, assume we are wrapping a C library that defines a type, | |
689 | @code{bottle_t}, and functions that can be passed @code{bottle_t *} | |
690 | pointers to manipulate them. We could write: | |
691 | ||
692 | @example | |
de6fb187 LC |
693 | (define-wrapped-pointer-type bottle |
694 | bottle? | |
1f4f7674 LC |
695 | wrap-bottle unwrap-bottle |
696 | (lambda (b p) | |
697 | (format p "#<bottle of ~a ~x>" | |
698 | (bottle-contents b) | |
aed9483b | 699 | (pointer-address (unwrap-bottle b))))) |
1f4f7674 LC |
700 | |
701 | (define grab-bottle | |
702 | ;; Wrapper for `bottle_t *grab (void)'. | |
703 | (let ((grab (pointer->procedure '* | |
704 | (dynamic-func "grab_bottle" libbottle) | |
705 | '()))) | |
706 | (lambda () | |
707 | "Return a new bottle." | |
708 | (wrap-bottle (grab))))) | |
709 | ||
710 | (define bottle-contents | |
711 | ;; Wrapper for `const char *bottle_contents (bottle_t *)'. | |
712 | (let ((contents (pointer->procedure '* | |
713 | (dynamic-func "bottle_contents" | |
714 | libbottle) | |
715 | '(*)))) | |
716 | (lambda (b) | |
717 | "Return the contents of B." | |
718 | (pointer->string (contents (unwrap-bottle b)))))) | |
719 | ||
720 | (write (grab-bottle)) | |
721 | @result{} #<bottle of Ch@^ateau Haut-Brion 803d36> | |
722 | @end example | |
723 | ||
724 | In this example, @code{grab-bottle} is guaranteed to return a genuine | |
725 | @code{bottle} object satisfying @code{bottle?}. Likewise, | |
726 | @code{bottle-contents} errors out when its argument is not a genuine | |
727 | @code{bottle} object. | |
728 | @end deffn | |
729 | ||
183a2a22 LC |
730 | Going back to the @code{scm_numptob} example above, here is how we can |
731 | read its value as a C @code{long} integer: | |
732 | ||
733 | @example | |
734 | (use-modules (rnrs bytevectors)) | |
735 | ||
736 | (bytevector-uint-ref (pointer->bytevector numptob (sizeof long)) | |
737 | 0 (native-endianness) | |
738 | (sizeof long)) | |
739 | @result{} 8 | |
740 | @end example | |
741 | ||
742 | If we wanted to corrupt Guile's internal state, we could set | |
743 | @code{scm_numptob} to another value; but we shouldn't, because that | |
744 | variable is not meant to be set. Indeed this point applies more widely: | |
745 | the C API is a dangerous place to be. Not only might setting a value | |
746 | crash your program, simply accessing the data pointed to by a dangling | |
747 | pointer or similar can prove equally disastrous. | |
71725997 | 748 | |
b9264dc5 AW |
749 | @node Foreign Structs |
750 | @subsubsection Foreign Structs | |
71725997 | 751 | |
b9264dc5 AW |
752 | Finally, one last note on foreign values before moving on to actually |
753 | calling foreign functions. Sometimes you need to deal with C structs, | |
754 | which requires interpreting each element of the struct according to the | |
755 | its type, offset, and alignment. Guile has some primitives to support | |
756 | this. | |
757 | ||
758 | @deffn {Scheme Procedure} sizeof type | |
5f6ffd66 | 759 | @deffnx {C Function} scm_sizeof (type) |
b9264dc5 AW |
760 | Return the size of @var{type}, in bytes. |
761 | ||
762 | @var{type} should be a valid C type, like @code{int}. | |
763 | Alternately @var{type} may be the symbol @code{*}, in which | |
764 | case the size of a pointer is returned. @var{type} may | |
765 | also be a list of types, in which case the size of a | |
766 | @code{struct} with ABI-conventional packing is returned. | |
767 | @end deffn | |
71725997 | 768 | |
b9264dc5 | 769 | @deffn {Scheme Procedure} alignof type |
5f6ffd66 | 770 | @deffnx {C Function} scm_alignof (type) |
b9264dc5 AW |
771 | Return the alignment of @var{type}, in bytes. |
772 | ||
773 | @var{type} should be a valid C type, like @code{int}. | |
774 | Alternately @var{type} may be the symbol @code{*}, in which | |
775 | case the alignment of a pointer is returned. @var{type} may | |
776 | also be a list of types, in which case the alignment of a | |
777 | @code{struct} with ABI-conventional packing is returned. | |
71725997 AW |
778 | @end deffn |
779 | ||
b9264dc5 AW |
780 | Guile also provides some convenience methods to pack and unpack foreign |
781 | pointers wrapping C structs. | |
71725997 | 782 | |
b9264dc5 AW |
783 | @deffn {Scheme Procedure} make-c-struct types vals |
784 | Create a foreign pointer to a C struct containing @var{vals} with types | |
785 | @code{types}. | |
786 | ||
787 | @var{vals} and @code{types} should be lists of the same length. | |
788 | @end deffn | |
789 | ||
790 | @deffn {Scheme Procedure} parse-c-struct foreign types | |
791 | Parse a foreign pointer to a C struct, returning a list of values. | |
792 | ||
793 | @code{types} should be a list of C types. | |
794 | @end deffn | |
795 | ||
796 | For example, to create and parse the equivalent of a @code{struct @{ | |
797 | int64_t a; uint8_t b; @}}: | |
71725997 AW |
798 | |
799 | @example | |
b9264dc5 AW |
800 | (parse-c-struct (make-c-struct (list int64 uint8) |
801 | (list 300 43)) | |
802 | (list int64 uint8)) | |
803 | @result{} (300 43) | |
71725997 | 804 | @end example |
71725997 | 805 | |
b9264dc5 AW |
806 | As yet, Guile only has convenience routines to support |
807 | conventionally-packed structs. But given the @code{bytevector->foreign} | |
808 | and @code{foreign->bytevector} routines, one can create and parse | |
809 | tightly packed structs and unions by hand. See the code for | |
810 | @code{(system foreign)} for details. | |
71725997 | 811 | |
726b8ba3 AW |
812 | |
813 | @node Dynamic FFI | |
814 | @subsection Dynamic FFI | |
815 | ||
71725997 AW |
816 | Of course, the land of C is not all nouns and no verbs: there are |
817 | functions too, and Guile allows you to call them. | |
818 | ||
2ee07358 | 819 | @deffn {Scheme Procedure} pointer->procedure return_type func_ptr arg_types |
5f6ffd66 | 820 | @deffnx {C Procedure} scm_pointer_to_procedure (return_type, func_ptr, arg_types) |
71725997 AW |
821 | Make a foreign function. |
822 | ||
823 | Given the foreign void pointer @var{func_ptr}, its argument and | |
824 | return types @var{arg_types} and @var{return_type}, return a | |
825 | procedure that will pass arguments to the foreign function | |
826 | and return appropriate values. | |
827 | ||
828 | @var{arg_types} should be a list of foreign types. | |
b9264dc5 AW |
829 | @code{return_type} should be a foreign type. @xref{Foreign Types}, for |
830 | more information on foreign types. | |
71725997 AW |
831 | @end deffn |
832 | ||
b9264dc5 | 833 | Here is a better definition of @code{(math bessel)}: |
726b8ba3 | 834 | |
b9264dc5 AW |
835 | @example |
836 | (define-module (math bessel) | |
837 | #:use-module (system foreign) | |
838 | #:export (j0)) | |
71725997 | 839 | |
b9264dc5 | 840 | (define libm (dynamic-link "libm")) |
71725997 | 841 | |
b9264dc5 | 842 | (define j0 |
2ee07358 LC |
843 | (pointer->procedure double |
844 | (dynamic-func "j0" libm) | |
845 | (list double))) | |
b9264dc5 | 846 | @end example |
71725997 | 847 | |
b9264dc5 | 848 | That's it! No C at all. |
71725997 | 849 | |
b9264dc5 AW |
850 | Numeric arguments and return values from foreign functions are |
851 | represented as Scheme values. For example, @code{j0} in the above | |
852 | example takes a Scheme number as its argument, and returns a Scheme | |
853 | number. | |
71725997 | 854 | |
b9264dc5 AW |
855 | Pointers may be passed to and returned from foreign functions as well. |
856 | In that case the type of the argument or return value should be the | |
857 | symbol @code{*}, indicating a pointer. For example, the following | |
858 | code makes @code{memcpy} available to Scheme: | |
71725997 | 859 | |
b9264dc5 AW |
860 | @example |
861 | (define memcpy | |
862 | (let ((this (dynamic-link))) | |
2ee07358 LC |
863 | (pointer->procedure '* |
864 | (dynamic-func "memcpy" this) | |
865 | (list '* '* size_t)))) | |
b9264dc5 AW |
866 | @end example |
867 | ||
868 | To invoke @code{memcpy}, one must pass it foreign pointers: | |
869 | ||
870 | @example | |
07d22c02 | 871 | (use-modules (rnrs bytevectors)) |
71725997 | 872 | |
183a2a22 LC |
873 | (define src-bits |
874 | (u8-list->bytevector '(0 1 2 3 4 5 6 7))) | |
b9264dc5 | 875 | (define src |
183a2a22 | 876 | (bytevector->pointer src-bits)) |
b9264dc5 | 877 | (define dest |
183a2a22 | 878 | (bytevector->pointer (make-bytevector 16 0))) |
71725997 | 879 | |
183a2a22 | 880 | (memcpy dest src (bytevector-length src-bits)) |
b9264dc5 | 881 | |
183a2a22 | 882 | (bytevector->u8-list (pointer->bytevector dest 16)) |
b9264dc5 AW |
883 | @result{} (0 1 2 3 4 5 6 7 0 0 0 0 0 0 0 0) |
884 | @end example | |
885 | ||
886 | One may also pass structs as values, passing structs as foreign | |
887 | pointers. @xref{Foreign Structs}, for more information on how to express | |
888 | struct types and struct values. | |
889 | ||
890 | ``Out'' arguments are passed as foreign pointers. The memory pointed to | |
891 | by the foreign pointer is mutated in place. | |
71725997 AW |
892 | |
893 | @example | |
b9264dc5 AW |
894 | ;; struct timeval @{ |
895 | ;; time_t tv_sec; /* seconds */ | |
896 | ;; suseconds_t tv_usec; /* microseconds */ | |
897 | ;; @}; | |
898 | ;; assuming fields are of type "long" | |
899 | ||
900 | (define gettimeofday | |
2ee07358 | 901 | (let ((f (pointer->procedure |
b9264dc5 AW |
902 | int |
903 | (dynamic-func "gettimeofday" (dynamic-link)) | |
904 | (list '* '*))) | |
905 | (tv-type (list long long))) | |
906 | (lambda () | |
907 | (let* ((timeval (make-c-struct tv-type (list 0 0))) | |
908 | (ret (f timeval %null-pointer))) | |
909 | (if (zero? ret) | |
910 | (apply values (parse-c-struct timeval tv-type)) | |
911 | (error "gettimeofday returned an error" ret)))))) | |
912 | ||
913 | (gettimeofday) | |
914 | @result{} 1270587589 | |
915 | @result{} 499553 | |
71725997 AW |
916 | @end example |
917 | ||
b9264dc5 | 918 | As you can see, this interface to foreign functions is at a very low, |
33186356 LC |
919 | somewhat dangerous level@footnote{A contribution to Guile in the form of |
920 | a high-level FFI would be most welcome.}. | |
921 | ||
922 | @cindex callbacks | |
923 | The FFI can also work in the opposite direction: making Scheme | |
924 | procedures callable from C. This makes it possible to use Scheme | |
925 | procedures as ``callbacks'' expected by C function. | |
926 | ||
927 | @deffn {Scheme Procedure} procedure->pointer return-type proc arg-types | |
928 | @deffnx {C Function} scm_procedure_to_pointer (return_type, proc, arg_types) | |
929 | Return a pointer to a C function of type @var{return-type} | |
930 | taking arguments of types @var{arg-types} (a list) and | |
931 | behaving as a proxy to procedure @var{proc}. Thus | |
932 | @var{proc}'s arity, supported argument types, and return | |
933 | type should match @var{return-type} and @var{arg-types}. | |
934 | @end deffn | |
935 | ||
936 | As an example, here's how the C library's @code{qsort} array sorting | |
937 | function can be made accessible to Scheme (@pxref{Array Sort Function, | |
938 | @code{qsort},, libc, The GNU C Library Reference Manual}): | |
939 | ||
940 | @example | |
941 | (define qsort! | |
2ee07358 LC |
942 | (let ((qsort (pointer->procedure void |
943 | (dynamic-func "qsort" | |
944 | (dynamic-link)) | |
945 | (list '* size_t size_t '*)))) | |
33186356 LC |
946 | (lambda (bv compare) |
947 | ;; Sort bytevector BV in-place according to comparison | |
948 | ;; procedure COMPARE. | |
949 | (let ((ptr (procedure->pointer int | |
950 | (lambda (x y) | |
951 | ;; X and Y are pointers so, | |
952 | ;; for convenience, dereference | |
953 | ;; them before calling COMPARE. | |
954 | (compare (dereference-uint8* x) | |
955 | (dereference-uint8* y))) | |
956 | (list '* '*)))) | |
957 | (qsort (bytevector->pointer bv) | |
958 | (bytevector-length bv) 1 ;; we're sorting bytes | |
959 | ptr))))) | |
960 | ||
961 | (define (dereference-uint8* ptr) | |
962 | ;; Helper function: dereference the byte pointed to by PTR. | |
963 | (let ((b (pointer->bytevector ptr 1))) | |
964 | (bytevector-u8-ref b 0))) | |
965 | ||
966 | (define bv | |
967 | ;; An unsorted array of bytes. | |
968 | (u8-list->bytevector '(7 1 127 3 5 4 77 2 9 0))) | |
969 | ||
970 | ;; Sort BV. | |
971 | (qsort! bv (lambda (x y) (- x y))) | |
972 | ||
973 | ;; Let's see what the sorted array looks like: | |
974 | (bytevector->u8-list bv) | |
975 | @result{} (0 1 2 3 4 5 7 9 77 127) | |
976 | @end example | |
977 | ||
978 | And voil@`a! | |
979 | ||
980 | Note that @code{procedure->pointer} is not supported (and not defined) | |
981 | on a few exotic architectures. Thus, user code may need to check | |
982 | @code{(defined? 'procedure->pointer)}. Nevertheless, it is available on | |
983 | many architectures, including (as of libffi 3.0.9) x86, ia64, SPARC, | |
984 | PowerPC, ARM, and MIPS, to name a few. | |
71725997 | 985 | |
726b8ba3 AW |
986 | @c Local Variables: |
987 | @c TeX-master: "guile.texi" | |
988 | @c End: |