* pws-19 @ 1999-05-19 11:27 Peter Stephenson 1999-05-19 21:33 ` pws-19 Vin Shelton 1999-05-20 7:10 ` pws-19 Andrej Borsenkow 0 siblings, 2 replies; 4+ messages in thread From: Peter Stephenson @ 1999-05-19 11:27 UTC (permalink / raw) To: Zsh hackers list 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: pws-19 1999-05-19 11:27 pws-19 Peter Stephenson @ 1999-05-19 21:33 ` Vin Shelton 1999-05-20 7:10 ` pws-19 Andrej Borsenkow 1 sibling, 0 replies; 4+ messages in thread From: Vin Shelton @ 1999-05-19 21:33 UTC (permalink / raw) To: Zsh hackers list Peter, Just FYI: you left Sven's patch 6268 from your list, but it seems to have been applied to pws-19. - vin ^ permalink raw reply [flat|nested] 4+ messages in thread
* RE: pws-19 1999-05-19 11:27 pws-19 Peter Stephenson 1999-05-19 21:33 ` pws-19 Vin Shelton @ 1999-05-20 7:10 ` Andrej Borsenkow 1999-05-20 7:45 ` pws-19 Peter Stephenson 1 sibling, 1 reply; 4+ messages in thread From: Andrej Borsenkow @ 1999-05-20 7:10 UTC (permalink / raw) To: Peter Stephenson, Zsh hackers list > > 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: pws-19 1999-05-20 7:10 ` pws-19 Andrej Borsenkow @ 1999-05-20 7:45 ` Peter Stephenson 0 siblings, 0 replies; 4+ messages in thread From: Peter Stephenson @ 1999-05-20 7:45 UTC (permalink / raw) To: Zsh hackers list "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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~1999-05-20 8:10 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-05-19 11:27 pws-19 Peter Stephenson 1999-05-19 21:33 ` pws-19 Vin Shelton 1999-05-20 7:10 ` pws-19 Andrej Borsenkow 1999-05-20 7:45 ` pws-19 Peter Stephenson
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).