On Jul 29, 2008, at 7:24 AM, devzero2000 wrote:

>
> On Mon, Jul 28, 2008 at 4:53 PM, Jeff Johnson <n3npq@mac.com> wrote:
> This likely needs some context ...
>
> rpmmtree derived from BSD still has some *BSD peculier API usages,  
> strtouq(), asprintf() and strvis()
> just to mention some of the portability issues.
>
> Normally I'd just rewrite rpmmtree.c to avoid the portability  
> issues, and will likely do that with
> rpmmtree(8) somewhen soon as well.
>
> However, rpm.org is making heavy usage of something called  
> "rasprintf", so some sort
> of malloc'ing printf simplifies stealing code from rpm.org. I prefer  
> the well known asprintf(3) API,
> which is often present in system libraries, to a home rolled custom  
> malloc'ing printf gadget API.
>
> strtouq(3) is almost certainly going to have some portability issues  
> somewhere (my guess). Dunno
> the best answer, time to find out.
>
> http://mirbsd.org/htman/i386/man3/strtoul.htm
>
> So it is possibile to use strtoul(3) in place of strouq. And   
> strtoul  is more portable , standard (C99) compliant
>

The problem reported needs solving on QNX, which either does not have  
strtoul, or (more likely)
that the sizeof(unsigned long) < sizeof(off_t). The strtouq() is being  
used to convert st->st_size
in a stat(2) structure.

But yes strtoul() is likely more portable than strtouq().

>
>
>
>
> And I still don't know what to do with the strvis(3) usages in  
> rpmmtree. Internal to rpmmtree
> a while longer hurts little for now.
>
> Perhaps it is necessary to introduce libedit, that have the  
> implementation of strvis, internal to RPM - for portabilty.
> Or, perhaps better, to use internal only  the strvis function of  
> vis.c in libedit
>
> http://koji.fedoraproject.org/packages/libedit/2.11/1.20080712cvs.fc10/src/libedit-2.11-1.20080712cvs.fc10.src.rpm
>

Yes, libedit is the library where where strvis() is usually found on  
Linux. But there's portability to
other non-linux platforms needed too, and tying rpmmtree => -ledit in  
order to use strvis() limits
where rpmmtree can be compiled.

Personally, strvis(3) does not seem to be a very useful function imho.  
I would have rewritten rpmmtree
to eliminate strvis(3) usage already if strvis(3) were used directly  
in rpm code paths. Interoperability
with system mtree(8) on Mac OS X and *BSD is what caused me to leave  
strvis(3) within rpmmtree.

So there's lots of solutions, just no clear indication of which  
solution is "best" yet.

hth

73 de Jeff