From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-return-6319-mason-zsh=primenet.com.au@sunsite.auc.dk>
Received: (qmail 26371 invoked from network); 20 May 1999 07:11:29 -0000
Received: from sunsite.auc.dk (130.225.51.30)
  by ns1.primenet.com.au with SMTP; 20 May 1999 07:11:29 -0000
Received: (qmail 15537 invoked by alias); 20 May 1999 07:11:20 -0000
Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm
Precedence: bulk
X-No-Archive: yes
X-Seq: 6319
Received: (qmail 15529 invoked from network); 20 May 1999 07:11:18 -0000
From: "Andrej Borsenkow" <borsenkow.msk@sni.de>
To: "Peter Stephenson" <pws@ibmth.df.unipi.it>,
        "Zsh hackers list" <zsh-workers@sunsite.auc.dk>
Subject: RE: pws-19
Date: Thu, 20 May 1999 11:10:35 +0400
Message-ID: <004501bea28f$db10d8d0$21c9ca95@mow.siemens.ru>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="koi8-r"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <9905191127.AA40561@ibmth.df.unipi.it>

>
> 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