Re: [Zutils-bug] Version 1.0-rc3 of zutils released

2012-10-31 Thread Antonio Diaz Diaz

Dagobert Michelsen wrote:

The code in zcat
str.insert( 0U, 1, '1' );

matches the first declaration (0U is a position in str),


for 32 bit this is correct, however on 64 bit the type is 0UL which causes the
ambiguity. When I change the type to 0UL it works for 64 bit, but not 32 bit.
What is needed is a type that works on both 32 and 64 bit.


I have just tried on a 64 bit Slackware with gcc 4.5.2 and both 0U and 0 
alone work perfectly without a warning, even with --pedantic.


Moreover, in zdiff.cc line 127 you can find
  do { fifonames[i].insert( pos, 1, codes[n % num_codes] );

where 'pos' is an unsigned int. I guess it can be considered a bug in 
the compiler to promote 'pos' to size_type and fail to do the same with 
0 or 0U.



Best regards,
Antonio.

___
Zutils-bug mailing list
Zutils-bug@nongnu.org
https://lists.nongnu.org/mailman/listinfo/zutils-bug


Re: [Zutils-bug] Version 1.0-rc3 of zutils released

2012-10-29 Thread Dagobert Michelsen
Hi Antonio,

Am 29.10.2012 um 12:07 schrieb Antonio Diaz Diaz ant_d...@teleline.es:
 Version 1.0-rc3 of zutils is ready for testing here
 http://download.savannah.gnu.org/releases/zutils/zutils-1.0-rc3.tar.gz
 http://download.savannah.gnu.org/releases/zutils/zutils-1.0-rc3.tar.lz
 
 The md5sums are:
 82b40d9e87c161dba70664007416e767  zutils-1.0-rc3.tar.gz
 2a1c6ea7a2f62bde43474d0e39d727c8  zutils-1.0-rc3.tar.lz
 
 Please, test it and report any bugs you find.

I just did a test on Solaris 9 Sparc with Sun Studio 12 and got the following 
issues:

1. requires inttypes.h instead of stdint.h and requires extra include signal.h

There are due the old OS and probably not worth fixing:
  
http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/zutils/trunk/files/0001-Use-inttypes.h-instead-of-stdint.h-and-add-signal.h.patch

2. Wrong type on str.insert: should be (char *) NULL instead of 0L

This leads to ambiguous casts either on 32 bit or with 0UL on 64 bit. This can
easily be corrected with
  
http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/zutils/trunk/files/0004-Avoid-ambiguity-between-char-and-unsigned-long-on-sp.patch

Apart from that it works fine with 32 and 64 bit on spark, i386 and amd64.

 Zcat, zcmp, zdiff and zgrep are improved replacements for the shell scripts 
 provided with GNU gzip. Ztest is unique to zutils.


We have been traditionally naming these with uppercase Z. I remember you were
talking to the gzip team about adjusting the names to remove the collisions.
Has this been settled?


Best regards

  -- Dago


-- 
You don't become great by trying to be great, you become great by wanting to 
do something,
and then doing it so hard that you become great in the process. - xkcd #896


___
Zutils-bug mailing list
Zutils-bug@nongnu.org
https://lists.nongnu.org/mailman/listinfo/zutils-bug


Re: [Zutils-bug] Version 1.0-rc3 of zutils released

2012-10-29 Thread Antonio Diaz Diaz

Hello Dagobert. Thanks for the feedback.

Dagobert Michelsen wrote:

I just did a test on Solaris 9 Sparc with Sun Studio 12 and got the following 
issues:

1. requires inttypes.h instead of stdint.h and requires extra include signal.h

There are due the old OS and probably not worth fixing:


I think so. And in the case of signal.h I think it is a bug in the OS 
because zutils already includes csignal.




2. Wrong type on str.insert: should be (char *) NULL instead of 0L

This leads to ambiguous casts either on 32 bit or with 0UL on 64 bit. This can
easily be corrected with
  
http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/zutils/trunk/files/0004-Avoid-ambiguity-between-char-and-unsigned-long-on-sp.patch


I think this is also a bug in the OS.

The two declarations involved are (from bits/basic_string.h):
  basic_string insert(size_type __pos, size_type __n, _CharT __c);
and
  void insert(iterator __p, size_type __n, _CharT __c);


The code in zcat
  str.insert( 0U, 1, '1' );

matches the first declaration (0U is a position in str), while
  str.insert( str.begin(), 1, '1' );

would match the second. But I do not think the proposed patch
  str.insert( (char *) NULL, 1, '1' );

should match either. (char *) NULL is neither an integer nor a valid 
iterator.


In fact gcc does not accept the patch unless -fpermissive is used. And 
even so gcc converts it to a position instead of an iterator or a 
pointer. If you need to fix it, I recommend you to use str.begin().




Zcat, zcmp, zdiff and zgrep are improved replacements for the shell scripts 
provided with GNU gzip. Ztest is unique to zutils.


We have been traditionally naming these with uppercase Z. I remember you were
talking to the gzip team about adjusting the names to remove the collisions.
Has this been settled?


Well, it has been settled here[1], as explained in the INSTALL file:

If you are installing zutils along with GNU gzip and want to keep the 
gzip scripts, the recommended method is to configure gzip as follows:


   ./configure --program-transform-name='s/^z/gz/'

This renames, at installation time, the gzip scripts and man pages to 
'gzcat', 'gzcat.1', etc, avoiding the name clashing with the programs 
and man pages from zutils.


[1] http://lists.gnu.org/archive/html/bug-gzip/2012-01/msg6.html


Best regards,
Antonio.

___
Zutils-bug mailing list
Zutils-bug@nongnu.org
https://lists.nongnu.org/mailman/listinfo/zutils-bug


Re: [Zutils-bug] Version 1.0-rc3 of zutils released

2012-10-29 Thread Dagobert Michelsen
Hi Antonio,

Am 29.10.2012 um 17:28 schrieb Antonio Diaz Diaz ant_d...@teleline.es:
 2. Wrong type on str.insert: should be (char *) NULL instead of 0L
 This leads to ambiguous casts either on 32 bit or with 0UL on 64 bit. This 
 can
 easily be corrected with
  
 http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/zutils/trunk/files/0004-Avoid-ambiguity-between-char-and-unsigned-long-on-sp.patch
 
 I think this is also a bug in the OS.
 
 The two declarations involved are (from bits/basic_string.h):
  basic_string insert(size_type __pos, size_type __n, _CharT __c);
 and
  void insert(iterator __p, size_type __n, _CharT __c);
 
 The code in zcat
  str.insert( 0U, 1, '1' );
 
 matches the first declaration (0U is a position in str),

for 32 bit this is correct, however on 64 bit the type is 0UL which causes the
ambiguity. When I change the type to 0UL it works for 64 bit, but not 32 bit.
What is needed is a type that works on both 32 and 64 bit.

 while
  str.insert( str.begin(), 1, '1' );
 
 would match the second. But I do not think the proposed patch
  str.insert( (char *) NULL, 1, '1' );
 
 should match either. (char *) NULL is neither an integer nor a valid 
 iterator.
 
 In fact gcc does not accept the patch unless -fpermissive is used. And even 
 so gcc converts it to a position instead of an iterator or a pointer. If you 
 need to fix it, I recommend you to use str.begin().

I see.

 Zcat, zcmp, zdiff and zgrep are improved replacements for the shell scripts 
 provided with GNU gzip. Ztest is unique to zutils.
 We have been traditionally naming these with uppercase Z. I remember you 
 were
 talking to the gzip team about adjusting the names to remove the collisions.
 Has this been settled?
 
 Well, it has been settled here[1], as explained in the INSTALL file:
 
 If you are installing zutils along with GNU gzip and want to keep the gzip 
 scripts, the recommended method is to configure gzip as follows:
 
   ./configure --program-transform-name='s/^z/gz/'
 
 This renames, at installation time, the gzip scripts and man pages to 
 'gzcat', 'gzcat.1', etc, avoiding the name clashing with the programs and man 
 pages from zutils.
 
 [1] http://lists.gnu.org/archive/html/bug-gzip/2012-01/msg6.html


Ok.


Best regards

  -- Dago

-- 
You don't become great by trying to be great, you become great by wanting to 
do something,
and then doing it so hard that you become great in the process. - xkcd #896


___
Zutils-bug mailing list
Zutils-bug@nongnu.org
https://lists.nongnu.org/mailman/listinfo/zutils-bug