Re: Release of version 4.14.2 of sharutils

[Eric Blake]

On 12/13/2014 01:11 PM, Bruce Korb wrote:
> 
> GNU sharutils consists of two pairs of utilities: shar and unshar, and
> uuencode and uudecode.  "shar" makes so-called shell archives out of
> many files, preparing them for transmission by electronic mail
> services (converting binary data to ascii representations, breaking
> the text into multiple shar scripts, etc.).  "unshar" is the safe way
> to extract and reassemble the original files.  It will automatically
> strip off the mail headers and other introductory text.
> 
> "uuencode" and "uudecode" are programs that convert binary files into
> ascii text so that the original data can pass through the email system
> without having intermediate hosts "fixing" the files en route.
> 
> This is a bug fix release for version 4.14 of sharutils
> 
> Version 4.14.2 - December 2014, by Bruce Korb
> * translation updates
> * use ftello, fseeko and fflush
> * augment copyright marks in shar.c and shar-std.def
> * Happy 2014 copyright dates, just in time for 2015 :)
> * fix up man pages (use newer doc generation code)

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:

FAIL: shar-3
============

/usr/src/sharutils-4.14.2-1.x86_64/build/src/unshar: Found no shell
commands in ../shar-3-0002.shar
/tmp/shar-3-2868.d/base-2868 and shar-3.d differ
...

My guess is that shar-3-0002.shar is an empty file, because shar dumped
core when trying to dereference the truncated integer. By the way,
basename() is non-portable, and not thread-safe; it's better to use
gnulib's base_name() function.

You also ought to fix this warning:

unshar.c: In function 'load_file':
unshare.c:318:21: warning: initialization discards 'const' qualifier
from pointer target type [enabled by default]
     char * pz_tmp = get_env_tmpdir();
                     ^
although I don't think that one is fatal.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature