Re: Release of version 4.14.2 of sharutils

Thank you.  I think it is probably just easier to roll my own.
"basename" not being an especially difficult function to write.
Anyway, I'll look at it come the new year as I am leaving in a few minutes.
Thanks again

On 12/22/14 10:43, Eric Blake wrote:
> 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.
>