author | Junio C Hamano <junkio@cox.net> | |
Fri, 20 Jan 2006 21:33:20 +0000 (13:33 -0800) | ||
committer | Junio C Hamano <junkio@cox.net> | |
Sun, 22 Jan 2006 03:33:22 +0000 (19:33 -0800) | ||
commit | 0bdd79af62e8621359af08f0afca0ce977348ac7 | |
tree | 4ddea26c599119dfaa75d5b5c7e4b3a891aa6318 | tree | snapshot |
parent | 5df9140c92349a807952628a04ee94b65c5bead5 | commit | diff |
Undef DT_* before redefining them.
When overriding DT_* macro detection with NO_D_TYPE_IN_DIRENT (recent
Cygwin build problem, which hopefully is already fixed in their CVS
snapshot version), we define DTYPE() macro to return just "we do not
know", but still needed to use DT_* macro to avoid ifdef in the code
we use them. If the platform defines DT_* macro but with unusable
d_type, this would have resulted in us redefining these preprocessor
symbols.
Admittedly, that would be just a couple of compilation warnings, and
on Cygwin at least this particular problem is transitory (the problem
is already fixed in their CVS snapshot version), so this is a low
priority fix.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When overriding DT_* macro detection with NO_D_TYPE_IN_DIRENT (recent
Cygwin build problem, which hopefully is already fixed in their CVS
snapshot version), we define DTYPE() macro to return just "we do not
know", but still needed to use DT_* macro to avoid ifdef in the code
we use them. If the platform defines DT_* macro but with unusable
d_type, this would have resulted in us redefining these preprocessor
symbols.
Admittedly, that would be just a couple of compilation warnings, and
on Cygwin at least this particular problem is transitory (the problem
is already fixed in their CVS snapshot version), so this is a low
priority fix.
Signed-off-by: Junio C Hamano <junkio@cox.net>
cache.h | diff | blob | history |