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

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.

- Raw text -