Path: ...!3.eu.feeder.erje.net!2.eu.feeder.erje.net!feeder.erje.net!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: "undefined behavior"?
Date: Fri, 14 Jun 2024 00:55:12 +0100
Organization: A noiseless patient Spider
Lines: 48
Message-ID: <87o784xusf.fsf@bsb.me.uk>
References: <666a095a$0$952$882e4bbb@reader.netnews.com>
	<8t3k6j5ikf5mvimvksv2t91gbt11ljdfgb@4ax.com>
	<666a18de$0$958$882e4bbb@reader.netnews.com>
	<87y1796bfn.fsf@nosuchdomain.example.com>
	<666a2a30$0$952$882e4bbb@reader.netnews.com>
	<87tthx65qu.fsf@nosuchdomain.example.com>
	<v4dtlt$23m6i$1@dont-email.me> <NoEaO.2646$J8n7.2264@fx12.iad>
	<v4fc5j$2cksu$1@dont-email.me> <v4ff97$2d8l1$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 14 Jun 2024 01:55:13 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="857528a8b109889a6f438cbb5df2d776";
	logging-data="2646195"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+o9DWIfb5cYnEDnhal0sUe8QkXc8XJgRc="
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:6Pyqx42LyclNWUjcaw9/tfDSEhc=
	sha1:GyMsu1TUoNnyS92AUJehNk/IIWA=
X-BSB-Auth: 1.1f0074677d25b84aee9b.20240614005512BST.87o784xusf.fsf@bsb.me.uk
Bytes: 3350

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On 13/06/2024 19:01, bart wrote:

>> And here it just gets even uglier. You also get situations like this:
>>      uint64_t i=0;
>>      printf("%lld\n", i);
>> This compiles OK with gcc -Wall, on Windows64. But compile under Linux64
>> and it complains the format should be %ld. Change it to %ld, and it
>> complains under Windows.
>> It can't tell you that you should be using one of those ludicrous macros.
>> I've also just noticed that 'i' is unsigned but the format calls for
>> signed. That may or may not be deliberate, but the compiler didn't say
>> anything.
>>
> Exactly. We can't have this just to print out an integer.

This is how C works.  There's no point in moaning about it.  Use another
language or do what you have to in C.

> In Baby X I provide a function called bbx_malloc(). It's is guaranteed
> never to return null. Currently it just calls exit() on allocation failure.
> But it also limits allocation to slightly under INT_MAX. Which should be
> plenty for a Baby program, and if you want more, you always have big boy's
> malloc.

And if you need to change the size?

> But at a stroke, that gets rid of any need for size_t,

But sizeof, strlen (and friends like the mbs... and wcs... functions),
strspn (and friend), strftime, fread, fwrite. etc. etc. all return
size_t.

For people taught to ignore size_t, care is also needed when calling
functions that take size_t arguments as the signed to unsigned
conversion can cause surprises when not flagged by the compiler.  I
don't know if I am right, but I would bet that many of the "don't bother
with size_t" crowd are also in the "don't bother with all those warning
flags to the compiler" crowd.

> and long is very
> special purpose (it holds the 32 bit rgba values).

Isn't that rather wasteful when long is 64 bits?

-- 
Ben.