On Fri, Mar 29, 2019 at 5:05 PM Thomas Gummerer <t.gummerer@xxxxxxxxx> wrote: > > On 03/29, Matheus Tavares Bernardino wrote: > > On Thu, Mar 28, 2019 at 7:10 PM Thomas Gummerer <t.gummerer@xxxxxxxxx> wrote: > > > I notice that we are currently not using 'linkat()' anywhere else in > > > our codebase. It looks like it has been introduced in POSIX.1-2008, > > > which sounds fairly recent by git's standards. So I wonder if this is > > > really supported on all platforms that git is being built on. > > > > > > I also wonder what would need to be done on Windows if we were to > > > introduce this. I see we define the 'link()' function in > > > 'compat/mingw.c' for that currently, so I guess something similar > > > would be needed for 'linkat()'. I added Dscho to Cc for Windows > > > expertise. > > > > Ok, what if instead of using linkat() we use 'realpath(const char > > *path, char *resolved_path)', which will resolve any symlinks at > > 'path' and store the canonical path at 'resolved_path'? Then, we can > > still keep using link() but now, with the certainty that all platforms > > will have a consistent behaviour? (also, realpath() is POSIX.1-2001) > > Would that be a better idea? > > Yeah, I think that is a good idea. Note that 'realpath()' itself is > not used anywhere in our codebase either, but there is > 'strbuf_realpath()', that from reading the function documentation does > exactly what 'realpath()' would do. So using 'strbuf_realpath()' > would probably be the right thing to do here. Thanks. While I was looking for realpath() at git codebase (before I saw your email), I got a little confused: Besides strbuf_realpath() I also found real_path(), real_path_if_valid() and real_pathdup(). All these last three use strbuf_realpath() but they also initialize the struct strbuf internally and just return a 'char *', which is much convenient in some cases. What seems weird to me is that, whilst real_pathdup() releases the internally initialized struct strubuf (leaving just the returned string to be free'd by the user), the other two don't. So, if struct strbuf change in the future to have more dynamic allocated resources, these functions will also have to be modified. Also, since real_pathdup() can already do what the other two do, do you know if there is a reason to keep all of them? One last question: I found some places which don't free the string returned by, for example, real_path() (e.g., find_worktree() at worktree.c). Would it be a valid/good patch (or patches) to add free() calls in this places? (I'm currently trying to get more people here at USP to contribute to git, and maybe this could be a nice first contribution for them...)
