Re: about lposix

["Mike Panetta" <panetta.mike@...>]

ACK!  Sorry, I had open and fopen confused.  I believe that
open has to return an int.  Its fopen that uses the opaque data
structure.

Mike

On 10/17/06, Mike Panetta <panetta.mike@gmail.com> 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().

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