Re: openlog

[Sean Conner <sean@...>]

It was thus said that the Great Matthew Wild once stated:
> On 14 August 2013 05:02, Gary V. Vaughan <gary@vaughan.pe> wrote:
> > Hi Matthew,
> >
> > On Aug 13, 2013, at 8:29 PM, Matthew Wild <mwild1@gmail.com> wrote:
> >
> >> On 13 August 2013 14:13, dcharno <dcharno@comcast.net> wrote:
> >>> The GNU libc manual says the pointer to ident in openlog is retained and the memory shouldn't be freed. I noticed the openlog binding in luaposix doesn't do anything special to make sure the string isn't garbage collected and neither do most FFI bindings for syslog. I haven't experienced a problem (yet) so maybe it isn't an issue. How do people handle this in their bindings.
> >>
> >> This is one of the reasons we're not using luaposix in Prosody yet. We
> >> use this code, which works for us so far:
> >> http://hg.prosody.im/trunk/file/e8c79796ead9/util-src/pposix.c#l163
> >>
> >> It would be nice to handle this well in luaposix.
> >
> > I don't personally use all the calls available in luaposix, but I am very happy to apply patches to improve the parts I don't use myself… or even write patches for those parts if someone sends me a test (any smallish self contained Lua snippet is perfect!) that will verify my implementation is correct :)
> 
> A year or two ago I evaluated luaposix, with a hope to switch Prosody
> to using it instead of our own little library. Ultimately it was a
> bunch of minor issues that put me off at the time. I had a small email
> exchange with Reuben Thomas at the time. I'll include a relevant
> section from one of my emails:

  I've pretty much written my own wrappers for Posix functions [1], grouped
by what makes sense to me (files and directory APIs in one module; process
related functions in another; network related functions in a third, etc).  

  As for openlog(), right now I have to make sure that whatever I pass in
remains viable, but I see the solution you use and I think I'll be adapting
that as well.  

> 1) Silly API decisions
> 
> Minor on the surface, but makes the library and code using it just
> seem unnecessarily ugly. One example, getpid() returns a table. I see
> someone was trying to make it smart, but getpid("pid") just seems
> silly. Let's see about getuid()... oh, no, that's getpid("uid"),
> despite a uid not being anything like a pid. How about setting it?
> setpid("u", ...). Sigh.
> 
> My approach would be to bind individual POSIX functions as tightly as
> possible, and only deviating when necessary to keep the interface to
> Lua clean and usable. It seems like the current API can't decide
> whether it wants to be high or low level.

  That's pretty much the approach I took, except that I don't have a
getpid() function (org.conman.process.PID contains the current PID).  But I
do have setuid(), setgid(), getuid(), getgid(), etc.  

> 3) Error reporting
> 
> In Prosody's POSIX library we have fixed error strings such as
> "permission-denied", which are more important than the
> locale-dependent human-readable strings given by strerror() (ideally
> we would have a function to return strerror() for any error name).

  I handled that by setting the __index() method on org.conman.errno:

	errno = require "org.conman.errno"
	print(errno[23])

  I also have (as far as I can determine) a predefined set of errors defined
in org.conman.errno so one can check for specific errors:

	if err = errno.EINTR then
	 ...
	elseif err == errno.ETIMEDOUT then
	 ...
	end

 I should also note that all of my Posix routines return errno as the second
result (if no error, then it returns 0).  I'm consistent in this, because
consistency is good.

> 4) Documentation
> 
> A big issue, especially with the current bizarre API - there's
> basically no way to use the library without reading the source, unless
> I've missed the documentation somewhere (I do find it hard to believe
> a library that has been around so long has none).

  Alas, that's a problem I have ... 

  -spc 

[1]	https://github.com/spc476/lua-conmanorg