>> My libsslfd would use them if available.  It contains evil magic to
>> hook read(),write() etc so that stdio can have SSL transport shoved
>> underneath - works a treat for ftp/ftpd.

>This is just the sort of thing that I would say *shouldn't* use them;
>what you really want to be using is not libc's read and write, but
>rather the read and write from "the next layer down", which may or may
>not be the raw libc one.  Consider layering a similar library atop
>yours - if that next layer goes straight to libc, your layer is
>(incorrectly) bypassed.

I know its not ideal - that's why I was asking about such a layering 
mechanism some time ago.  For instance I'd like to see 

	stdio
	libsslfd <=> libssl
	libsocks

work.  Right now libsslfd and sock5 are incompatible - looked at 
supporting socks a while back and decided it was too hard - easier
to just use a http proxy.

So yes __libc_read() etc is not a total solution, but it is available
on at least a few OS's (Solaris and Linux at least) and is better than 
libsslfd calling syscall().  Also making the above layering "simply work"
would probably be NetBSD specific for a long time (if not forever).

--sjg