dana@dino.bellcore.com (Dana A. Chee) (08/23/88)
In article <15419@shemp.CS.UCLA.EDU> casey@admin.cognet.ucla.edu (Casey Leedom) writes: In article <DANA.88Aug22090308@dino.bellcore.com> dana@dino.bellcore.com (Dana A. Chee) writes: > > readfiles = (1 << yourSocket) | (1 << Xfd ); > n = select(32, &readfiles, 0, 0, 0); > > if( readfiles & (1 << Xfd) ) > ... Just being picky here. But if you're not going to use the fd_set stuff from <sys/types.h>, you should at least get the types you are using right. The above should read: readfiles = (1L << yourSocket) | (1L << Xfd ); n = select(32, &readfiles, (long *)0, (long *)0, (struct timeval *)0); if( readfiles & (1L << Xfd) ) Casey Ah yes, portability. After receiving your news item about something called fd_set, I went hunting for it. There seems to be a complete FD_SET, FD_ISSET, etc. under Ultrix, but no such functions on a Sun (3.5). Also, the definition of select on both the Sun and the Ultrix machines is: select(int ncnt, int *read, int *write, int *execp, struct timeval *time); So the values are to be pointers to ints, not pointers to longs. So much for portability. Enjoy! -- +*************************************************************************+ * Dana Chee (201) 829-4488 * * Bellcore * * Room 2Q-250 * * 445 South Street ARPA: dana@bellcore.com * * Morristown, NJ 07960-1910 UUCP: {gateways}!bellcore!dana * +*************************************************************************+
dana@BELLCORE.BELLCORE.COM ("Dana A. Chee") (08/23/88)
In article <15419@shemp.CS.UCLA.EDU> casey@admin.cognet.ucla.edu (Casey Leedom) writes: In article <DANA.88Aug22090308@dino.bellcore.com> dana@dino.bellcore.com (Dana A. Chee) writes: > > readfiles = (1 << yourSocket) | (1 << Xfd ); > n = select(32, &readfiles, 0, 0, 0); > > if( readfiles & (1 << Xfd) ) > ... Just being picky here. But if you're not going to use the fd_set stuff from <sys/types.h>, you should at least get the types you are using right. The above should read: readfiles = (1L << yourSocket) | (1L << Xfd ); n = select(32, &readfiles, (long *)0, (long *)0, (struct timeval *)0); if( readfiles & (1L << Xfd) ) Casey Ah yes, portability. After receiving your news item about something called fd_set, I went hunting for it. There seems to be a complete FD_SET, FD_ISSET, etc. under Ultrix, but no such functions on a Sun (3.5). Also, the definition of select on both the Sun and the Ultrix machines is: select(int ncnt, int *read, int *write, int *execp, struct timeval *time); So the values are to be pointers to ints, not pointers to longs. So much for portability. Enjoy! -- +*************************************************************************+ * Dana Chee (201) 829-4488 * * Bellcore * * Room 2Q-250 * * 445 South Street ARPA: dana@bellcore.com * * Morristown, NJ 07960-1910 UUCP: {gateways}!bellcore!dana * +*************************************************************************+
casey@admin.cognet.ucla.edu (Casey Leedom) (08/25/88)
In article <8808240628.AA12711@kth.se> dana@bellcore.com (Dana Chee) writes: > Ah yes, portability. After receiving your news item about something > called fd_set, I went hunting for it. There seems to be a complete > FD_SET, FD_ISSET, etc. under Ultrix, but no such functions on a Sun > (3.5). Also, the definition of select on both the Sun and the Ultrix > machines is: > > select(int ncnt, int *read, int *write, int *execp, struct timeval *time); > > So the values are to be pointers to ints, not pointers to longs. So much > for portability. The fd_set type and associated macros are new to 4.3BSD; Sun hasn't adopted them yet. That's a problem associated with introducing anything new, even if for the purpose of portability. The other problem however is institutionalizing VAXism. It's bad enough that we have novice programmers being trained up on machines where long == int and with little encouragement to know the difference between those or any other types, but when the man pages themselves are wrong ... You'll find similar errors in all the 4.2BSD signal manual pages sigsetmask(2), sigblock(2), sigpause(2), etc. with reference to signal masks; in tty(4) with reference to the pointer argument to FIONREAD; in select(2) with reference to file descriptor mask sets; and in ffs(3) with reference to its argument. (Can't use it for file descriptor set masks if it doesn't take longs.) What's even worse, the tty(4) manual page used to be correct in 2.9BSD and was changed to be incorrect. All programmers should be forced to write and port programs on a machine where long != int (and preferably where (char *) != int). Casey