Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!cmcl2!adm!xadmx!gaw@mercury.acc.com
From: gaw@mercury.acc.com (...Glen............)
Newsgroups: comp.unix.wizards
Subject: sockets
Message-ID: <19700@adm.BRL.MIL>
Date: 21 May 89 17:37:28 GMT
Sender: news@adm.BRL.MIL
Lines: 40

Hello everyone.  I am looking into porting the UNIX socket library to
an IBM system running a TCP/IP networking software package.  The socket
library will only provide sockets in the AF_INET domain.  The C-compiler
that I will be using attempts to emulate the UNIX environment as much
as possible on the IBM system.  Many of the standard UNIX function calls
(such as open, fopen, fscanf, etc) are available to the C programmer.
Since some of the built in functions like read and write can work with
an inode and also a socket, I think that I would have to front end these
calls to look at the file descriptor type field and then call either the
built in routine if it is a request for an inode or to the routine that
I will write if the file descriptor references a socket.  I don't see any
problems with that.  How about you????

My next question is: "Is it possible for a user program in UNIX to
use open to acquire a file descriptor and then using another function
convert this file descriptor to a FILE pointer(such as those returned from
the fopen() call)?  The reason I ask this is that if it is possible for a
user process to convert from file descriptors to file pointers it is then
possible to use socket to open a file descriptor, convert it to a FILE pointer
and then attempt to do a fprintf or fscanf on the socket.  If this is possible
I would have to front end these FILE pointer functions also with code
similar to that specified above.  I know it is possible to go from a
FILE pointer to a file descriptor using the fileno(FILE *) macro.  Is it
possible to convert in the other direction?

Other functions which I will have to front end would be ioctl, perror,
and fcntl.  Does anyone see any problems with the above, other areas
of concern, suggestions, etc?

I would like to make this interface as closely UNIX compatible as possible.
I also want to make it versatile enough that futher applications such as
NFS will be able to use the library for all of its networking needs.
Any and all help or information will be greatly appreciated.

Please respond to    gaw@acc-sb-unix.arpa

Thank you,

Glen Warholic
Advanced Computer Communications