Gary V. Vaughan

Hi Zevv, 1. The plan is to make minimal bindings in `ext/posix/posix.c`, and then to write more pleasant/Luaish wrappers in `lib/posix/sys.lua`, however for backwards compatibility we might put a wrapper...

I don't think we need to break backward compatibility, but otherwise yes, please go ahead and fix the return values if you'd like. Before the next release, I'll patch up...

Lua 5.1 only has 53 bits to storeintegers, so this is a luaposix issue that affects any wrapped API that accepts or returns a long int that doesn't fit in...

That looks about right. Thanks! I'm not sure whether this all works already with Lua >=5.3 by virtue of 64bit support, so it would be good to add test cases...

Actually, thinking about it a bit more, maybe it would be better for backwards compatibility to always return at least 53bits from eg lseek, just as we do now, but...

I think that would be more difficult to use in client code that wants to work on multiple Lua versions than this: ```lua r, big = seek(blah) if r and...

Hi Enrico, Thanks for the heads up on this. > On 5 Jul 2015, at 16:07, Enrico [email protected] wrote: > > The bug was filed on the Debian package, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789534...

I'm not sure there is such a thing. I've been following the SUSv3 specifications for posix from the open group. You can reach the relevant pages from the most recent...

Agreed. AFAICT that implies that lposix.c needs to add some normalisation for its own return values so that Lua code gets a consistent view... The specification clearly states that when...

Thanks for the swift response! :) I think its more to do with whether the luaposix socket calls provide everything needed to check whether the functionality required is available before...