On 08/03, Thomas Rast wrote:
> Thomas Gummerer <t.gumme...@gmail.com> writes:
>
> > Since the cache-tree data is saved as part of the directory data,
> > we have already read it, when we want to read the cache-tree. The
> > cache-tree then only has to be converted from the directory data.
>
> I think the first sentence is wrong. You have already read it at the
> very beginning of reading the index format, when you parsed the
> directory records, haven't you?
Yes, that's what I wanted to say, I'll rephrase this.
> > The cache-tree isn't lexically sorted, but after the pathlen at
> > each level, therefore the directories have to be reordered with
> > respect to the ondisk layout.
>
> I'm not a native speaker either, but I think this does't parse well.
> Maybe
>
> The cache-tree data is arranged in a tree, with the children sorted by
> pathlen at each node. So we have to rebuild this format from the
> on-disk directory list.
Thanks, that sounds better.
> > + for (i = 0; i < subtree_nr; i++) {
> > + struct cache_tree *sub;
> > + struct cache_tree_sub *subtree;
> > + char *buf, *name;
> > +
> > + name = "";
> > + buf = strtok(down[i].de->pathname, "/");
>
> man 3 strtok says
>
> Be cautious when using these functions. If you do use them, note
> that:
>
> * These functions modify their first argument.
>
> * These functions cannot be used on constant strings.
>
> * The identity of the delimiting character is lost.
>
> * The strtok() function uses a static buffer while parsing, so it's
> not thread safe. Use strtok_r() if this matters to you.
>
> I don't think the last point will be a problem, but what about modifying
> the argument?
Hrm the function is only called at the end of read_index_v5, after
which we don't need the directory entries anymore. If we want to use
the directory entries for a new in-memory format later however, we
should probably change it. Maybe a comment for the cache_tree_convert_v5
function would be enough?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
