X-Authentication-Warning: acp3bf.physik.rwth-aachen.de: broeker owned process doing -bs
Date: Mon, 6 Aug 2001 13:26:55 +0200 (MET DST)
From: Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
X-Sender: broeker AT acp3bf
To: djgpp-workers AT delorie DOT com
Subject: Re: ls bug
In-Reply-To: <3B6BC349.946B4D25@phekda.freeserve.co.uk>
Message-ID: <Pine.LNX.4.10.10108061306320.17612-100000@acp3bf>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
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

On Sat, 4 Aug 2001, Richard Dawe wrote:

> 'ls' casts st_size to an unsigned type - uintmax_t - which is defined to
> be unsigned long long:
[...]
> 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. The rules for conversion
of a negative integer into an unsigned type require that the result
is correct 'modulo the new unsigned_max + 1'. The effect is that

	(unsigned long long) -1

is equivalent to

	(unsigned long long)(long long)-1

not

	(unsigned long long)(unsigned long) -1

Reference: K&R2, Appendix A.6.2 on "Integer Conversion".

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

-- 
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.