On 12/22/2014 11:25 AM, Eric Blake wrote:
You still have a bug that needs fixing:
shar.c: In function 'walktree':
shar.c:577:5: warning: implicit declaration of function 'basename'
[-Wimplicit-function-declaration]
restore_name = basename (local_name_copy);
^
shar.c:577:18: warning: assignment makes pointer from integer without a
cast [enabled by default]
restore_name = basename (local_name_copy);
^
On 32-bit cygwin, 'int' and 'void*' are the same width, so the correct
thing happens in spite of the bad coding, and the testsuite passes; but
on 64-bit cygwin, since 'int' is truncated, and the memory layout
intentionally sticks heap pointers outside the first 4G, you are
corrupting the value returned by basename by integer truncation before
re-expansion back to a pointer, and this causes a testsuite failure:
Sure enough, this patch was sufficient to avoid the testsuite failure on
64-bit cygwin:
diff --git i/src/shar.c w/src/shar.c
index fd7cf41..47ad514 100644
--- i/src/shar.c
+++ w/src/shar.c
@@ -50,6 +50,7 @@ static const char cright_years_z[] =
# include <limits.h>
#endif
#include <time.h>
+#include <libgen.h>
#include "inttostr.h"
#include "liballoca.h"
That said,
basename() is non-portable, and not thread-safe; it's better to use
gnulib's base_name() function.
I still stand by this advice; gnulib intentionally does not guarantee
<libgen.h> (and it is missing on at least mingw), because basename() is
not the right function to be using if you care about systems with drive
letters.