From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26777 invoked from network); 20 May 1999 08:10:29 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 20 May 1999 08:10:29 -0000 Received: (qmail 19588 invoked by alias); 20 May 1999 08:10:14 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 6320 Received: (qmail 19573 invoked from network); 20 May 1999 08:10:08 -0000 Message-Id: <9905200745.AA18430@ibmth.df.unipi.it> To: "Zsh hackers list" Subject: Re: pws-19 In-Reply-To: ""Andrej Borsenkow""'s message of "Thu, 20 May 1999 11:10:35 DFT." <004501bea28f$db10d8d0$21c9ca95@mow.siemens.ru> Date: Thu, 20 May 1999 09:45:40 +0200 From: 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 Tel: +39 050 844536 WWW: http://www.ifh.de/~pws/ Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy