>>> Does anyone else think having __libc_read, __libc_write etc would
>>> be handy?
>> Maybe, though I have trouble imagining what could reasonably use
>> them.
> 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.

>> #define __CONCATDEFER(x,y) __CONCAT(x,y)

> Thanks, that's the sort of thing I was after.  It works ok with cc -E
> but not with cpp which is what is currently used when building the
> syscall entries in libc.  cpp appears to be equiv to cc -traditional
> -E which may be a bug.

/usr/bin/cpp is a shell script.  The comments say

# Transitional front end to CCCP to make it behave like (Reiser) CCP:
#       specifies -traditional
#       doesn't search gcc-include

I too have been unable to get cpp to (not CCP, whatever the comment may
think) do the concatenation you want.  The closest I've been able to
come is to generate __libc_/**/read, which I don't think as will do
anything sensible with.  (I haven't been able to make it rescan that so
as to trash the comment....)

Perhaps the build procedure for the syscalls should be fixed?

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B