Hi David, Duy,
If you need to re-roll your 'dt/index-helper' branch, could you please
consider squashing these patches into the relevant patch (equivalent to
commit 12909da4 ("index-helper: new daemon for caching index and related
stuff", 06-04-2016)).
The above commit causes the cygwin build to throw a warning (many times)
about the redefinition of the UNIX_PATH_MAX macro, viz:
CC credential-store.o
In file included from cache.h:4:0,
from credential-store.c:1:
git-compat-util.h:1060:0: warning: "UNIX_PATH_MAX" redefined
#define UNIX_PATH_MAX 92
^
In file included from git-compat-util.h:212:0,
from cache.h:4,
from credential-store.c:1:
/usr/include/sys/un.h:18:0: note: this is the location of the previous
definition
#define UNIX_PATH_MAX 108
^
Which is quite easy to confirm:
$ find /usr/include -iname '*.h' | xargs grep -n UNIX_PATH_MAX
/usr/include/sys/un.h:18:#define UNIX_PATH_MAX 108
/usr/include/sys/un.h:22: char sun_path[UNIX_PATH_MAX]; /*
108 bytes of socket address */
$ gcc -dD -E git-compat-util.h 2>/dev/null | grep -n 'un\.h'
8716:# 1 "/usr/include/sys/un.h" 1 3 4
8717:# 12 "/usr/include/sys/un.h" 3 4
$ gcc -dD -E git-compat-util.h 2>/dev/null | grep -n 'UNIX_PATH_MAX'
8724:#define UNIX_PATH_MAX 108
32675:#define UNIX_PATH_MAX 92
$
So, a simple fix would look like:
diff --git a/git-compat-util.h b/git-compat-util.h
index 0e35c13..6d65132 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -1043,7 +1043,7 @@ struct tm *git_gmtime_r(const time_t *, struct tm *);
#define getc_unlocked(fh) getc(fh)
#endif
-#ifdef __linux__
+#if defined(__linux__) || defined(__CYGWIN__)
#define UNIX_PATH_MAX 108
#elif defined(__APPLE__) || defined(BSD)
#define UNIX_PATH_MAX 104
... since you are allowed to redefine a macro to the same token sequence
(modulo some strange whitespace rules).
However, assuming the <sys/un.h> header is defining the UNIX_PATH_MAX
macro, why even try to #define it again. So, maybe put an
#ifndef UNIX_PATH_MAX
...
#endif
around the entire block. But then, why on earth are you doing this at all?
Let's look on linux:
$ find /usr/include -iname '*.h' | xargs grep -n UNIX_PATH_MAX
/usr/include/valgrind/vki/vki-linux.h:754:#define VKI_UNIX_PATH_MAX 108
/usr/include/valgrind/vki/vki-linux.h:758: char
sun_path[VKI_UNIX_PATH_MAX]; /* pathname */
/usr/include/linux/un.h:6:#define UNIX_PATH_MAX 108
/usr/include/linux/un.h:10: char sun_path[UNIX_PATH_MAX]; /* pathname */
$ gcc -dD -E git-compat-util.h | grep -n 'un\.h'
14119:# 1 "/usr/include/x86_64-linux-gnu/sys/un.h" 1 3 4
14120:# 19 "/usr/include/x86_64-linux-gnu/sys/un.h" 3 4
$ gcc -dD -E git-compat-util.h | grep -n 'UNIX_PATH_MAX'
36788:#define UNIX_PATH_MAX 108
$
Ah, interesting, ... despite having a header that does indeed define the
UNIX_PATH_MAX macro, the compiler is not using that header, but another
one which doesn't. Well, blow me down. ;-)
So, the approach taken by patch #1 is to forget about UNIX_PATH_MAX and
simply use sizeof(address.sun_path) instead!
The second and third patches are simply 'mild suggestions' for other
minor issues I noticed while looking into these warnings.
ATB,
Ramsay Jones
Ramsay Jones (3):
index-helper: fix UNIX_PATH_MAX redefinition error on cygwin
index-helper: convert strncpy to memcpy
index-helper: take extra care with readlink
git-compat-util.h | 17 -----------------
index-helper.c | 4 ++--
read-cache.c | 15 +++++++++++++--
3 files changed, 15 insertions(+), 21 deletions(-)
--
2.8.0
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
