From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-return-6574-mason-zsh=primenet.com.au@sunsite.auc.dk>
Received: (qmail 21699 invoked from network); 10 Jun 1999 14:02:30 -0000
Received: from sunsite.auc.dk (130.225.51.30)
  by ns1.primenet.com.au with SMTP; 10 Jun 1999 14:02:30 -0000
Received: (qmail 16085 invoked by alias); 10 Jun 1999 14:02:16 -0000
Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm
Precedence: bulk
X-No-Archive: yes
X-Seq: 6574
Received: (qmail 16077 invoked from network); 10 Jun 1999 14:02:15 -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: PATCH: pws-21: minor fixes
Date: Thu, 10 Jun 1999 18:01:24 +0400
Message-ID: <002101beb349$b9cb3740$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)
In-Reply-To: <9906100906.AA23684@ibmth.df.unipi.it>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

>
> I looked again at Andrej's logfile from compiling with
> --enable-lfs, and it
> was even less interesting than the first time.  I've only made a couple of
> changes to the use of long integers, where it's just possible a
> user-supplied string might be too long.  Otherwise, there are still places
> where there are conversions for things like the lengths of strings, sizes
> of windows, return values, pids, line numbers, times (time_t is
> used fairly
> consistently for these and is usually 32-bit) and so on, where there
> doesn't seem any point in using longer integers.
>

One thing, that still bothers me, is mapfile. In case of LFS (64-on-32)
address space is most probably limited to 32 bits, that means, it is
impossible to map large file. I do not supose, anybody would do this on
purpose, but what happens if somebody makes mistake? Currently file size is
silently passed to mmap ... that truncates it and (in worst case) maps some
part of file. And even worse, can file be truncated as a result?

Or am I just paranoid?

/andrej