=2D----BEGIN PGP SIGNED MESSAGE-----
> When I hacked SB-GROVEL to support POSIX for UFFI, I added a new
> OPAQUE-TYPE declaration:
> (:opaque-type dir-ptr-t "DIR *"
> "Opaque type that represents an open directory stream")
> The "opendir" declaration then becomes:
> (:function opendir ("opendir" dir-ptr-t (name :cstring)))
I think this is basically the same as=20
(sb-alien:define-alien-type dirent-t (* t))
though obviously if you're using uffi you probably don't want to use
sb-alienb directly, so I can see why you did this.
> For a DIRENT, the declaration looks like:
> (:structure dirent-t ("struct dirent"
> (d_name :cstring "d_name" "char *")))
> The auxiliary C program will generate an declaration like:
> (define-sparse-struct dirent-t 268 ((d_name, :cstring 11 256)))
> This indicates that any DIRENT-T is 268 bytes long, with a "d_name"
> field 256 bytes long starting at byte 11. It uses the standard
> technique of "sizeof"s and subtracting field addresses. Note that
> there may be other fields, but we don't care about them. We generated
> the declaration from the POSIX spec.
For what it's worth, the usual sb-grovel processor will cope with
partial struct definitions too. The new feature in Derek's version is
that it recognises :cstring as a type - and obviously, that it
generates uffi definitions, not sb-alien stuff directly.
> concerned. And because you're defining a real structure, you don't
> have to use the DEFINE-C-ACCESSOR memcpy hack to get data in and out
> of the fields. My declaration of "readdir" ends up being:
Yeah, this is a problem for sb-grovel in its current form. There are,
1) There's no exported functional interface (as opposed to macro-
based interface) to ALIEN, and I didn't want to have user code
grovelling around extensively in the alien type system innards.
(This was back in the days when I first wrote db-sockets, for
CMUCL, and I was in even less of a position to unilaterally define
new CMUCL interfaces then than I am for SBCL now)
2) I wanted structures that would get GCed without having to worry
about creating finalisers for everything
3) As the eulogist said at the funeral of the dealer in stolen
property, it was a long time ago, and besides, the fence is dead.
On the subject of UFFI and POSIX more generally: I would like to
borrow/steal some of your POSIX work, but I'd really rather not have
SBCL contrib all depending on UFFI. Partly this is for size reasons,
partly because UFFI is a cross-implementation (if not portable, then
at least widely ported) project that's developed independently of
SBCL. (If I'm honest it's partly also a taste/prejudice issue: IMO
UFFI suffers from OAOOM issues - probably inescapable given the job it
does, but I don't want to get any on me)
http://www.cliki.net/ - Link farm for free CL-on-Unix resources=20
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
=2D----END PGP SIGNATURE-----