Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes:
>> ... The previously used call:
>>
>> has_symlink_leading_path(len, name);
>>
>> should be identically with the following call to lstat_cache():
>>
>> lstat_cache(len, name,
>> LSTAT_SYMLINK|LSTAT_DIR,
>> LSTAT_SYMLINK);
>
> I think the new interface looks worse.
>
> Why don't you just do a new inline function that says
>
> static inline int has_symlink_leading_path(int len, const char *name)
> {
> return lstat_cache(len, name,
> LSTAT_SYMLINK|LSTAT_DIR,
> LSTAT_SYMLINK);
> }
>
> and now you don't need this big patch, and people who don't care about
> those magic flags don't need to have them. End result: more readable code.
Excellent.
Not that I did not think a backward compatible macro is much easier to
read; after all, ce/ie you mention is a refactorizaton I did myself.
What I didn't think of was that posing the above question is a much better
way to extract a clear explanation why some of these lstat_cache() calls
have LSTAT_NOENT and some of them don't from the author. It is much
better way than my earlier attempt to do so.
> This is how git has done pretty much all "generalized" versions. See the
> whole ce_modified() vs ie_modified() thing: they're the same function,
> it's just that 'ce_modified()' is the traditional simpler interface that
> works on the default index, while ie_modified() is the "full" version that
> takes all the details that most uses don't even want to know about.
Yup, thanks for a praise ;-)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
