[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: about lposix
- From: "Mike Panetta" <panetta.mike@...>
- Date: Tue, 17 Oct 2006 14:10:22 -0400
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().
Mike
On 10/17/06, Ralph Hempel <rhempel@hempeldesigngroup.com> wrote:
Mike Panetta wrote:
> Someone somewhere please correct me if I am wrong, but I do not see a
> benefit to doing something other then POSIX, as there would be no real
> benefit in my mind. Even the windows specific stuff can be made to look
> posix I believe, and maybe where it can, it should? Maybe some concrete
> examples will sway my stubbornness :P
Here's an example then. Another app I have is a very memory constrained
embedded system. It's running Lua on an ARM7TDMI core in 256K of FLASH
and 64K of RAM.
I'm using the left over FLASH as a file system. It's a very simple
minded system, but has the concept of a root, heirarchy, etc, but it
does not have permissions, links, or other frills.
I still need things like open(), close(), cd(), pwd(), attributes(),
and an iterator for entries in a directory.
The underlying implementation is definitely not POSIX, but I'd
love to be able to test the Lua part of the code on a Windows
or BSD box using the same source code, but a different library
linked in.
Maybe I'm agreeing with you after all. It's the API that's important,
not whether it's implemented as POSIX or Windows, or whatever else
compliant underneath.
By using POSIX as a starting point though, it is much easier to
document where my custom library _differs_ from POSIX...
Ralph