pws-19

pws-19

[Peter Stephenson]

http://www.ifh.de/~pws/computing/
-rw-r--r--   1 pws  quadrics  759988 May 19 13:48 zsh-3.1.5-pws-19.tar.bz2
-rw-r--r--   1 pws  quadrics  368884 May 19 13:48 zsh-3.1.5-pws-19.doc.tar.gz
-rw-r--r--   1 pws  quadrics  249242 May 19 13:48 zsh-3.1.5-pws-19.doc.tar.bz2
-rw-r--r--   1 pws  quadrics  937267 May 19 13:48 zsh-3.1.5-pws-19.tar.gz

Please try --enable-lfs if you have a 32-bit system with large file
support.


Changes:

pws: 6263: incrementalappendhistory -> incappendhistory

pws: 6284, should have been in 6269: changes to large file support

pws: 6271: make sure -D_LARGEFILE_SOURCE is defined any time there are
other -D's for large file support

pws: 6272: correct even more mistakes some bozo (guess who) made with
rlim_t: put back RLIM_T_IS_UNSIGNED code.

Tatsuo Furukawa: 6273: don't need to defined _POSIX* flags specially on HPUX

Tatsuo Furukawa: 6274: updated form of zle_refresh patch

Sven: 6278: fix ${$(foo)...} to produce an array

Sven: 6283: compadd -U didn't quote characters properly

Sven: 6285: tty/job handling when executing some command in current shell
code within RHS of pipeline

pws: 6290: parameter module uses global scope, $parameters gets
unreadonlied, gcc warning

pws: 6291: zftp only checks for system type after login.

pws: 6294: typeset -U MANPATH performs uniqueness test straight away

Sven: 6298: (mult_isarr) ${*:-word} didn't use the default word

pws: 6299: if called as su* or -su*, zsh doesn't do sh emulation

Sven: 6301: expanded ignored prefix ignored for testing

Sven: 6302: more list_pipe intricacies

Tanaka Akira: 6303: _path_files: find files after symbolic link

pws: 6307, 6312: wider support for 64-bit integers on 32-bit architectures

pws: 6313: fix 6299 to use $SHELL to decide emulation

pws: 6314: in something like `{ false; } || true', errexit shouldn't be
used at all on the left of the ||

pws: unposted: updated some .distfiles

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy

Re: pws-19

[Vin Shelton]

Peter,
    Just FYI: you left Sven's patch 6268 from your list, but it seems to have 
been applied to pws-19.

  - vin

RE: pws-19

[Andrej Borsenkow]

>
> Please try --enable-lfs if you have a 32-bit system with large file
> support.
>

I get here quite a lot of warnings, that look like

glob.c  1261: [warning]:   CFE1859 result of small arithmetic used as wider
type
            r = b->_links - a->_links;
                ^

glob.c  1265: [warning]:   CFE1808 Cast of a large integral may lose bits
            return (int) ((*s & GS_DESC) ? -r : r);
                   ^

glob.c  2046: [warning]:   CFE1807 Conversion of a large integral may lose
bits
        int rstart = zstrtol(str+1,&dots,10), rend = 0, err = 0, rev = 0;
                     ^

(glob.c was just an example).

Some (many? all?) of them are probbaly harmless - this is the case, when the
value definitely fits in 32 bit. But still there are possible problems:

1. is there any chance, that some variables were not converted to 64 bit?
2. I already have seen weird side effects with casts between 32 and 64 bit
values. The problem is, signed/unsigned conversion between 32 bit values is
always harmless - it does not change bit pattern. Unfortunately, when
casting 32 bit value to 64 bit one, this becomes *very* important. That is,

unsigned i; long  j; i = (unsigned)j;

is noop, but

zulong i; long j; i = (unsigned)j;

does not sign extend - instead of small negative we get large positive
number.

I can post the messages here or send privately. Is anybody interested?

/andrej

Re: pws-19

[Peter Stephenson]

"Andrej Borsenkow" wrote:
> >
> > Please try --enable-lfs if you have a 32-bit system with large file
> > support.
> >
> 
> I get here quite a lot of warnings, that look like
> 
> glob.c  1261: [warning]:   CFE1859 result of small arithmetic used as wider
> type
> glob.c  1265: [warning]:   CFE1808 Cast of a large integral may lose bits
>             return (int) ((*s & GS_DESC) ? -r : r);
> glob.c  2046: [warning]:   CFE1807 Conversion of a large integral may lose
> bits

Those should be harmless; the zlong type was used in particular in glob.c
to support a size glob qualifier, while all the others fit comfortably into
32 bits, so I didn't change them.  There will probably be a lot of messages
about the result of zstrtol(); I think I caught the ones where it should
definitely be assigning to a zlong, and as it's used as the normal
int/string converter this sort of thing is inevitable.

> 1. is there any chance, that some variables were not converted to 64 bit?

It's not impossible, but I looked at everything that was already long to
decide whether it should be zlong.  I certainly didn't look at every int in
the source code.  File sizes, integer parameters, and arithmetic should be
OK, both internally and when doing I/O, but I can't necessarily guarantee
all contingent parts of the code.

> 2. I already have seen weird side effects with casts between 32 and 64 bit
> values. The problem is, signed/unsigned conversion between 32 bit values is
> always harmless - it does not change bit pattern. Unfortunately, when
> casting 32 bit value to 64 bit one, this becomes *very* important.

Luckily, I don't think there's too much of this.  In fact, there's only one
zulong, and that comes from a quantity which is already zlong.  Also, I
mostly avoided unsigned long when the quantity was going to become zlong,
since most of the occurrences were just to gain a little bit extra
precision.  The remaining unsigned longs in the stat module, for example,
are just the ones that don't need to be zlong.  If you can find specific
examples of problems, of course, I will take a look.

> I can post the messages here or send privately. Is anybody interested?

I'll take a look at them if you send them, maybe not today, maybe not
tomorrow, ...  It looks like there's going to be no escaping some warnings
with your compiler, however, since it doesn't seem sensible to change
everything to 64 bits.

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy