Marius Vollmer <mvo@zagadka.ping.de> wrote:
+---------------
| > | And what does this do?
| > | (printf "%s")
| > | Just crashing is not acceptable.
| > +---------------
| >
| > Gee, I don't know why not??!? ;-} ;-}
| > It "just crashes" when you do that in C, too!
|
| Yeah, but Scheme is not C. If you allow these `C-ish' semantics to
| creep into Scheme interfaces...
+---------------
My point was precisely that it is hard-to-impossible to connect Scheme
to some J-random piece of C code *without* exposing yourself to whatever
"crashes" are inherent in the C code! [But I joked about it, intending
a certain "we who are about to die" fatalism, and so got flamed for it
by multiple people. Oh well. So it goes. (*sigh*)]
[Note: By "printf", I was assuming that the original author was in fact
referring to the libc/stdio "printf", and not something of the same name
built in to their version of Scheme. *OF COURSE* if you implemented a native
Scheme version of "printf" you should check the format string against the
number of args passed, but (except under a very few and mostly obsolete
C compilers) the native libc/stdio/printf can't do that reliably.]
+---------------
| It clearly is a cool feature to just slurp in a C header file and then
| be able to call the C functions defined in it from Scheme. But I
| don't consider it to be a `solution' to the problem of using C
| libraries from Scheme.
+---------------
I would go further: In general, there is *NO* guaranteed "safe" way to use
arbitrary C libraries from within Scheme (or CL)... because arbitrary C
libraries have glorious bugs in them!!!
Not being a super logician (others on this list may be) I can't prove it,
but I suspect that the task of creating a "safe wrapper" around some piece
of previously-coded C is formally undecidable, and that's even assuming
you *have* the complete source code for the piece of C. But in most cases
we *don't* have the source code for the things we're trying to connect to
with our FFIs, and so it becomes utterly impossible for the resulting program
to be more reliable than the binary black box we're connecting to.
If the benefit of using existing libraries (specifically, not having to
re-write them in Scheme) is worth the inherent risk to you, fine. Various
FFI generators can ease the mechanical pain of getting the basic type
conversions and call sequences mostly right. But *nothing* can protect you
against inherently broken semantics in the foreign code -- you can't *NOT*
"allow these `C-ish' semantics to creep into Scheme interfaces" if you insist
on using external C code.
That was the point of my joke. It [ printf("%s"); ] crashes (or equiv.)
when you do it in a C program -- how could you possibly expect it *not*
to crash when you call it [the *same* underlying library routine] from
a Scheme program?
-Rob
p.s. Both SCM & MzScheme allow linking at run-time to ".so" extension
libraries. I have such a shared lib that some of my Scheme scripts use to
talk directly to memory-mapped hardware. Two of the routines in that lib:
static Scheme_Object *
peek(int argc, Scheme_Object **argv)
{ unsigned long p = scm2C_ulong(argv[0],1,"r32");
/*
* DANGER, Will Robinson! CoreDump City ahead...
*/
return C2scm_ulong(*(unsigned long *)p);
}
static Scheme_Object *
poke(int argc, Scheme_Object **argv)
{ unsigned long p = scm2C_ulong(argv[0],1,"w32");
/*
* DANGER, Will Robinson! CoreDump City ahead...
*/
*(unsigned long *)p = scm2C_ulong(argv[1],2,"w32");
return scheme_void;
}
Have I ever crashed my program? Yes, of course. Have I ever crashed the
whole *system*? Yes. Are the benefits of this program worth those risks?
Yes, ABSOLUTELY, in my particular application (interactively bringing up
newly-designed networking hardware in a lab without needing to rebuild
the kernel every time I want to try poking the hardware a new way). Would
those benefits be worth those risks for everyone else? HELL NO!
For another example, some versions of "STk" have been known to crash (some
versions of) the X server on certain systems -- not necessarily because there
was a bug in STk, but because there was an existing bug in the X libraries
on those systems [that STk called] that interacted with a bug in the X server,
and STk tickled that interaction in a way that other programs commonly used
on that system didn't. Does that make STk's FFI-to-X implementation "bad"?
Not at all. Just an example that when you link Scheme code to arbitrary C
code, you get exposure to whatever semantics are lurking in that C code.
-----
Rob Warnock, 7L-551 rpw3@sgi.com http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
2011 N. Shoreline Blvd. FAX: 650-933-4392
Mountain View, CA 94043 PP-ASEL-IA