[MLton] [PATCH] Review this patch and try it on other platforms, please (Kill runtime warnings)

Matthew Fluet fluet at tti-c.org
Sun Dec 2 18:02:45 PST 2007


On Sun, 2 Dec 2007, Florian Weimer wrote:
> * Matthew Fluet:
>
>> It is my understanding that the Single Unix Specification includes
>> POSIX (IEEE 1003.1 2004); it specifies that the 'request' parameter is
>> an 'int':
>>   http://www.opengroup.org/onlinepubs/009695399/functions/ioctl.html
>
> Technically, this is not the ioctl that is implemented by Linux.  Linux
> doesn't implement the STREAMS interfaces.

Good point; the FreeBSD ioctl function is provided by <sys/ioctl.h>, not 
<stropts.h>.  So, the POSIX ioctl is not the ioctl that is implemented by 
FreeBSD either.

A little more digging shows that ioctl is only used to implement 
Socket.Ctl.getNREAD and Socket.Ctl.getATMARK.  The latter could 
effectively be replaced by sockatmark from <sys/socket.h>:
   http://www.opengroup.org/onlinepubs/009695399/functions/sockatmark.html
For platforms where it may not exist, we could emulate it with ioctl; 
note, this solves the signedness of the ioctl request parameter problem, 
because we would be doing an explicit "ioctl(s,SIOCATMARK,&res)", not 
passing the request parameter through the FFI.

I don't know if there is a function meant to be emulated by 
Socket.Ctl.getNREAD, though we could do a similar thing as above and 
implement a socknread function that does an explicit 
"ioctl(s,FIONREAD,&res)", again avoiding the signedness problem.

As a meta comment, I can see the utility for a Socket.Ctl.getNREAD 
function, but I can't understand the rationale for how it ended up in the 
Basis Library specification.  Everything else in the Socket.Ctl structure 
has a very obvious analog with POSIX <sys/socket.h> functions (including 
Socket.Ctl.getATMARK, since sockatmark is in the <sys/socket.h> interface 
to standardize common practice).  I would guess that the 
ioctl(s,FIONREAD,...) is also common practice, though I don't know why it 
wasn't standardized like sockatmark.




More information about the MLton mailing list