Re: Suggestion: Lua 5.3 -- a facility for creating and manipulting Lua file handles (C API)

[Sean Conner <sean@...>]

It was thus said that the Great Sir Pogsalot once stated:
> In response to Coda:
> 
> I don't agree that opening up file handle creation to the C side of Lua
> would mean we have to forgo an appropriate level of security.  Lua does
> have a fair bit of type checking code to make sure its receiving file
> handles in the io library... The easiest way to fool it is to take any
> userdata you want and set the metatable to the "FILE*" table in the
> registry -- if you use the right io function you can cause a segfault if it
> looks at non-existent members of the userdata.  This would be easier in Lua
> 5.1 because you have newproxy() to create a zero-sized userdata. :-)  Still
> -- *SECURITY* :D

  It's one thing to try to subvert security through a program, and
subverting security through a library.  In the former, yes, I would expect a
program not to trust much coming from the "outside world" and do quite a bit
of validation.  On the later, that's like having physical access to a
computer---it's game out and no amount of checking paremeters will save you. 
I, like Coda, have decided to trust the programmer [1].

> In response to Sean:
> 
> Unfortunately I am not too familiar with the ins and outs of using poll()
> or epoll() -- select() was the simplest for me to grasp and I did that by
> copying fd sets into tables and back.  Don't have much more to say about
> that...  :x

  All three do the same thing---tell you when a file is ready for reading or
writing.  How they go about it is different, but the interface I created at
least abstracts the details away.  I decided against a table approach, since
copying the file descriptors back and forth when calling select() or poll()
could get too expensive (that, and the fact that there's no array to use
with epoll()) and went with explicite calls to insert and remove entries.

> I have actually [successfully] written to a UDP-packeted socket with
> io.write(), but I didn't do more experimenting to see if io.read() worked
> just as well.  

  Hmm, I'd like to see the code for this, because until you changed the
buffering to none (:setvbuf('no')) or explicitely flushed the data
(file:flush()) then the data will just accumulate until (by default)
LUAL_BUFFERSIZE (which is BUFSIZ, defined by ANSI C) bytes have been
written (did I mention leaky abstractions?)  

> I think I'll go back on what I said about :getfd().  I don't like fds being
> known to the Lua side of things, but a fair number of libraries expect that
> method to exist.  It is somewhat common, but I think it only exists because
> people are representing files as different types (bad).  :>

  It's pervasive because the underlying implemention on quite a few
operating systems is that of file descpriptors, Unix being the most famous,
but it was also used by MS-DOS and by extension, Windows for some time. 
There's also a bunch of stuff you can set through ioctl() and fcntl(), as
well as tcgetattr(), tcsetattr(), tcsendbreak(), tcdrain(), tcflush() and
tcflow() (TTY stuff).  

> The main focus of my socket bindings is that I was trying to be as true to
> the C prototype as possible so it would be easy for beginners to take a C
> networking tutorial and translate it to Lua without much guessing or
> digging through documentation.  Sometimes I feel like details about
> luasocket are hard to find...

  The details about luasocket can be found in "UNIX Network Programming"
although the authors never talk about Lua.

  I personally, have found myself getting away a bit from a pure mirror of
the C API and have gone more for what, to me, makes more sense in Lua.  I
also concentrate more on IPv4, IPv6 and Unix sockets since basically, that's
all *I* care about (and frankly, in my opinion, those protocols won).  

> I like your socket option code in net.c though, it's much friendlier than
> what I tried to do by adding every defined CONSTANT I could and having a
> get/setsockopt().  

  Yeah, I like doing:

	socket.reuseaddr = true
	socket.nonblock  = true

  over

	int value = 1;
	setsockopt(socket,SOL_SOCKET,SO_REUSEADDR,&value,sizeof(int));

	value = fcntl(socket,F_GETFL,0);
	value |= O_NONBLOCK;
	fcntl(socket,F_SETFL,value);

> I'm jealous that you got netlua_interfaces() implemented ;-)  I need to
> give lsock similar functionality.  OH THE JOYS OF HAVING YET ANOTHER SOCKET
> LIBRARY :]

  It only works on Linux.  Solaris (the system I use at work) does not have
(or I have not found yet) that, and I haven't tried Mac OS-X yet.

  -spc

[1]	Such that if you pass in a NULL pointer, my library *will* segfault
	[2].  I operate under the "garbage in, garbage out" principle, or
	rather, "give me valid data, and I will return you valid data."

	See 

	https://github.com/spc476/SPCDNS/blob/master/src/codec.c

	for an example of this.

[2]	That is, if you disable assert().