Re: [PATCH] Make git prune remove temporary packs that look like write failures

["David Tweed" <david.tweed@gmail.com>]

On Feb 6, 2008 7:41 PM, Brandon Casey <casey@nrlssc.navy.mil> wrote:
> They use sprintf for the "%02x" part, but they use memcpy to copy the return
> of get_object_directory() into a fixed string and then append onto that,
> rather than repeatedly writing the same string over and over. Ok, there is one
> instance in builtin-prune.c that repeatedly writes path, but builtin-prune-packed.c
> does the memcpy thing.

Given I'm the only person (AFAICS from the list archives) who's ever
talked about failed temporary packs, I assume that almost everyone
using git is using filesystems with sufficient space that they don't
get write errors, so the path building will generally be done 0 times
per --prune. (Using a USB disk that's almost full, along with
occasionally filling up my /home with experiment output, is the
occasions I get them.) So I don't think efficiency is an issue. So the
big (genuine) question is: is a properly checked snprintf more or less
readable/canonical git style than doing more complicated strlcpy
things? (I know I need to really think about what the below is doing,
and what the correctness conditions are.)

> Something like:
>
>         char pathname[PATH_MAX];
>         ...
>
>         /* check length of dirname not too long */
>
>         memcpy(pathname, dirname, len);
>
>         if (len && pathname[len-1] != '/')
>                 pathname[len++] = '/';
>
>         ...
>
>         while ((de = readdir(dir)...) {
>                 if (!prefixcmp(...
>                         if (strlcpy(pathname + len, de->d_name, PATH_MAX - len)
>                             >= PATH_MAX - len) {
>                                 warning("too long path encountered: %s%s",
>                                         pathname, de->d_name);
>                                 continue;
>                         }
>
>                         ...

-- 
cheers, dave tweed__________________________
david.tweed@gmail.com
Rm 124, School of Systems Engineering, University of Reading.
"while having code so boring anyone can maintain it, use Python." --
attempted insult seen on slashdot