tar -p and usernames vs. uid's

[Rob Landley]

On Monday 08 May 2006 4:40 am, Natanael Copa wrote:
> > Sigh, more #ifdefs.  But it's an area of the code that's full of 'em
> > already, so I'll clean it up later.
>
> You wan't:
>
> if (CONFIG_FEATURE_BLABLA) {
>    ...
> } else {
>    ...
> }
>
> instead of
> #idef CONFIG_FEATURE_BLABLA
>   ...
> #else
>   ...
> #endif
>
> and let the optimizer handle it properly?
>
> I might be able to help you and submit a cleanup patch.

Yes.  The problem is that some of the variables are only defined inside 
#ifdefs, which doesn't mix with letting the optimizer remove unused code.  
(The optimizer will also remove unused variables off of the stack, but 
generally not out of structures, for alignment reasons.  This is another 
place the USE() macros come in...)

> > This adds a seemingly unrelated malloc.  Was that a bug, or just for
> > symmetry, or...?
>
> adding an unrelated malloc? where?

Sorry, thinko on my part.  I meant the memset after the malloc.

What I was thinking was "malloc plus memset is common enough we should have a 
bb_xzalloc(size).  Right now we have a bb_xcalloc which zeroes the memory but 
which also pointlessly takes two arguments but we never call it with a first 
argument other than 1, so I should replace bb_xcalloc() with bb_xzalloc() 
that takes one argument but zeroes its memory, fix up the current calls, and 
then look for memset() or bzero() calls in the code to see where that can be 
put to use."

But I didn't because I've got way too many half-finished cleanups like that in 
my tree right now and I'm trying to get them in rather than start more...

> The only seemingly unrelated additions would be the memset after an
> xmalloc in archival/libunarchive/init_handle.c which is a fix. The patch
> breaks cpio extraction without the memset, and probably the other
> archivers too, due to the uninitialized file_header struc.

Ok, as long as there's a reason for it.

> > On the whole, seems reasonable.  I'll try to get it in this evening,
> > which means I've got to go debug the tar patch, _after_ I get the llist_t
> > changes checked in, which were a spin-off from the sed.c global
> > coalescing brought up in the earlier message today, which reminds me that
> > the sed rewrite for proper null handling is still languishing in the
> > previous tree...
>
> Thanks!

Well, I debugged the tar speedup patch (size % limit != size & limit)

> > Right...
>
> You are doing great... ;-)

Thanks, but I think I'm just barely keeping my head above water at this 
point...

> > Rob
> > --
> > Never bet against the cheap plastic solution.

-- 
Never bet against the cheap plastic solution.