Re: about lposix

[Natanael Copa <natanael.copa@...>]

On Tue, 2006-10-17 at 14:15 -0400, Ralph Hempel wrote:
> Mike Panetta wrote:
> > But does it have to differ?  POSIX only states that open has to return a
> > data structure representing a file (a file descriptor, in most cases its
> > an int).  So why can't lposix's open() return an opaque userdata that
> > can be used in your underlying functions but look the same to Lualand?
> > Its still POSIX, and it still works on anything that has the concept of
> > open().
> 
> You're right, it does not have to differ, but it might. For example,
> when writing or reading the file descriptor, does the operation
> block until complete or buffer as much as possible and return what got
> transferred?
> 
> Maybe I'm being dense and am assuming that if it's POSIX
> compliant, then it's got signals, buffering, and all kinds
> of cruft that may be unimplementable on some systems.
> 
> Let me do some more reading and thinking...

Implementing an already well known existing standard (like posix) is
*way* much more easy than inventing a new one. Learning a well known api
is also much easier than learning a new (specially if it basicly do the
same things) Many things are non-issues for windows too, like chdir,
mkdir getenv.

The question is what posix funcs can't windows do, and then maybe do
something special there. Is there a list of posix things windows can't
do?

Natanael Copa