Subject: Re: adding __libc_read et al?
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
From: Simon J. Gerraty <email@example.com>
Date: 12/31/1999 06:39:17
>> Does anyone else think having __libc_read, __libc_write etc would be
>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.
Right now I use syscall(2) if available and failing that, I extract
read.o etc from libc.a and frob the labels :-)
Being able to use __libc_read() et al would be neater and possibly deal
with re-entrancy problems. Solaris at least, says syscall() is not
>I snipped out of your patch enough to play with, and find this works
>for me with -DPREFIX=whatever. I hope you can adapt it. (I had to
>diddle with it a little to make it suitable for direct cc -E runs, such
>as the first #define.)
>#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.
Anyway thanks for looking at this.