Sender: rich AT phekda DOT freeserve DOT co DOT uk
Message-ID: <3B6F032B.380D986B@phekda.freeserve.co.uk>
Date: Mon, 06 Aug 2001 21:50:51 +0100
From: Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i586)
X-Accept-Language: de,fr
MIME-Version: 1.0
To: djgpp-workers AT delorie DOT com
Subject: Re: ls bug
References: <Pine DOT LNX DOT 4 DOT 10 DOT 10108061306320 DOT 17612-100000 AT acp3bf>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

Hello.

Hans-Bernhard Broeker wrote:
> 
> On Sat, 4 Aug 2001, Richard Dawe wrote:
[snip]
> > This cast does not work. This seems strange - I would expect a cast
> > from signed long to unsigned long long to work. Wouldn't the value be
> > zero-extended to fill the unsigned long long?
> 
> Iff it's negative: no. It'll be sign-extended.
[snip]
> Reference: K&R2, Appendix A.6.2 on "Integer Conversion".

Thanks, I thought K&R would have the answer. It usually does.

> > material here.) Typecasting to unsigned long then uintmax_t seems to
> > work, but I think that's a hack rather than the solution.
> 
> A proper solution would only be to make st_size (unsigned) long long, of
> course...

Or perhaps put a configure test in to detect the size of off_t and then
cast to an unsigned integer with the same size, as suggested by Jim
Meyering (the Fileutils maintainer). He's not very keen on this idea
though, so I may end up just including a fix in the patches for the DJGPP
port.

Bye, Rich =]

-- 
Richard Dawe
http://www.phekda.freeserve.co.uk/richdawe/