On Mon, Nov 10, 2008 at 9:45 PM, Jeff Johnson <n3npq@mac.com> wrote:

>
> On Nov 10, 2008, at 3:26 PM, Ralf S. Engelschall wrote:
>
>>
>>>
>> In rpmio/macro.c you are using HAVE_MKDTEMP for portability reasons, but
>> here in lposix.c you are not using it. This let's lposix.c to break on
>> some platforms as mkdtemp(3) is a BSD/Linux thing. It for instance is
>> not available under Solaris...
>>
>>
> Is mkstemp avaialable on Solaris? There was another rpm.org patch to add
> mkstemp()
> bindings that was added 6 weeks ago or so ...
>

Yes, it is in Single Unix Specs (
http://www.opengroup.org/onlinepubs/009695399/functions/mkstemp.html).

See also http://docs.sun.com/app/docs/doc/819-2243/mkstemp-3c?a=view

In very old solaris (or SunOS) perhaps no anyway, but i have not this
knowledge.

On systems implementing POSIX.1-2008, mkdtemp() exists. But it is now only a
draft

Regards


> I'll put a
>        #ifdef  NOTYET
> around the mkdtemp() code, its hardly worth chasing mkdtemp portability for
> functionality that has no demonstrable purpose yet. I added because there
> is no way to create a unique dirpath with macros, and I'd eventually
> like to do more with lua instead of custom macro magic primitives. There's
> no provision
> for error returns with macro expansions for example.
>
> Retrofitting using tmpnam & mkdir is always possible too. I mostly just
> followed the same coding conventions that were already in local/lposix.c.
>
> I do believe that lua internal <-> external needs to be rethought.
> The goals of "flexibly extensible" <-> "reliably available" are
> intrinsically
> at odds.
>
> I dunno what the final answer for lua internal will be, there is a balance
> point
> there somewhere, I just don't know where the point lies yet.
>
> Other ideas?
>
> 73 de Jeff
>
>
> ______________________________________________________________________
> RPM Package Manager                                    http://rpm5.org
> Developer Communication List                        rpm-devel@rpm5.org
>