From: Martin Str|mberg <ams AT ludd DOT luth DOT se>
Message-Id: <200110092052.WAA16564@father.ludd.luth.se>
Subject: Re: Resend: DJGPP and files > 2GB
In-Reply-To: <3BC33F16.8E19850E@phekda.freeserve.co.uk> from Richard Dawe at "Oct 9, 2001 07:16:54 pm"
To: djgpp-workers AT delorie DOT com
Date: Tue, 9 Oct 2001 22:52:36 +0200 (MET DST)
X-Mailer: ELM [version 2.4ME+ PL54 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

According to Richard Dawe:
> An example of the problem is the handling of the st_size member of the
> stat structure. st_size is an off_t. This means that the maximum size that
> can be represented is 2GB - 1. Currently stat will return a large negative
> number, since off_t is signed (which caused ls to output a bogus size). If
> st_size cannot represent the file's size, stat is supposed to return -1
> and set errno to EOVERFLOW.
> 
> I don't think the library's current behaviour is good - who knows what
> effect silently returning bogus sizes for files >= 2GB will have?

As the possible values are -2^31 - 2^31-1 there no ambiguity (if
you're aware of that a negative value != -1 is really a big positive
one).

But I'm not against any improvements as that result might confuse
people.

How does the type offset_t fit into the ways of addressing the
problem (if you know)?


Right,

						MartinS