Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Ben Bacarisse <ben@bsb.me.uk>
Newsgroups: comp.lang.c
Subject: Re: What is your opinion about unsigned int u = -2 ?
Date: Fri, 02 Aug 2024 16:17:29 +0100
Organization: A noiseless patient Spider
Lines: 34
Message-ID: <87r0b7c5ti.fsf@bsb.me.uk>
References: <v8dfo9$1k7cg$1@dont-email.me>
	<pan$d2c8a$8c54ac9f$29a202e0$12c6ce86@invalid.invalid>
	<87bk2cecan.fsf@bsb.me.uk> <v8inds$2qpqh$1@dont-email.me>
	<v8iqnr$7l3c$1@news.xmission.com> <v8irje$2rolg$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Fri, 02 Aug 2024 17:17:30 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="0a4f19eb014006a9905721b780020a95";
	logging-data="3026806"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19AeVfcy2CVz890YSVCBhs5C6nRisZJZRs="
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:rECNqqXcfMcuQUTSTrntCM5M0uE=
	sha1:5R+l9+AVV1Ut5azvcOXEzbuN71w=
X-BSB-Auth: 1.976680312531612ea20f.20240802161729BST.87r0b7c5ti.fsf@bsb.me.uk
Bytes: 2592

Bart <bc@freeuk.com> writes:

> On 02/08/2024 15:33, Kenny McCormack wrote:
>> In article <v8inds$2qpqh$1@dont-email.me>,
>> Thiago Adams  <thiago.adams@gmail.com> wrote:
>> ...
>>> So it seams that anything is ok for unsigned but not for signed.
>>> Maybe because all computer gave same answer for unsigned but this is not
>>> true for signed?
>> I think it is because it wants to (still) support representations other
>> than 2s complement.  I think POSIX requires 2s complement, and I expect the
>> C standard to (eventually) follow suit.
>> 
>
> C23 assumes 2s complement. However overflow on signed integers will still
> be considered UB: too many compilers depend on it.
>
> But even if well-defined (eg. that UB was removed so that overflow just
> wraps as it does with unsigned), some here, whose initials may or may not
> be DB, consider such overflow Wrong and a bug in a program.
>
> However they don't consider overflow of unsigned values wrong at all,
> simply because C allows that behaviour.
>
> But I don't get it. If my calculation gives the wrong results because I've
> chosen a u32 type instead of u64, that's just as much a bug as using i32
> instead of i64.

I don't think *anyone* considers a program that produces the wrong
result to be have any less buggy simply because of the types used.  You
are ascribing to other views that I have never seen anyone express.

-- 
Ben.