Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: "A diagram of C23 basic types"
Date: Wed, 2 Apr 2025 11:33:17 +0200
Organization: A noiseless patient Spider
Lines: 91
Message-ID: <vsj08u$1gaus$1@dont-email.me>
References: <87y0wjaysg.fsf@gmail.com> <vsinf4$17d6t$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 02 Apr 2025 11:33:18 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="74a97941b726b117bb180f881e003081";
	logging-data="1584092"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18c5vpWPsFCJJ7VvVtB7XgxgGOCtDrAnkg="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:oemXtY+56jq73p0J0CieqQ6tjvQ=
In-Reply-To: <vsinf4$17d6t$1@dont-email.me>
Content-Language: en-GB
Bytes: 4672

On 02/04/2025 09:02, Janis Papanagnou wrote:
> On 02.04.2025 07:59, Alexis wrote:
>>
>> Thought people here might be interested in this image on Jens Gustedt's
>> blog, which translates section 6.2.5, "Types", of the C23 standard
>> into a graph of inclusions:
>>
>>    https://gustedt.wordpress.com/2025/03/29/a-diagram-of-c23-basic-types/
> 
> A nice overview. - I have questions on some of these types...
> 
> The _Decimal* types - are these just types with other implicit
> encodings, say, BCD encoded, or some such?
> 
> The nullptr_t seems to be a special beast concerning the "NULL"
> entity; what purpose does that type serve, where is it used?
> 

"nullptr_t" is the type of "nullptr".  And "nullptr" is always a null 
pointer constant, just like the literal "0".  But unlike "0", it can 
never be mistaken for an integer - thus compilers will be able to detect 
mistakes more easily.  Consider the three basic ways of specifying a 
null pointer, and how they can be converted to an integer:

int * p = 0;
int * q = NULL;
int * r = nullptr;

int a = 0;		// No complaints from the compiler!

int b = NULL;		// Usually an error
int c = (int) NULL;	// No complaints

int d = nullptr;	// Error
int e = (int) nullptr;	// Error
int f = (int) (void*) nullptr;		// You really mean it!


This is what makes "nullptr" safer, and thus a useful addition to C.  It 
is also consistent with C++, where "nullptr" is more important (for use 
in function overloads).

The type "nullptr_t" itself is unlikely to be particularly useful, but 
has to exist because "nullptr" needs a type.  It could conceivably be 
used in a _Generic, but I have not seen any applications of that.

> I see the 'bool' but recently seen mentioned some '_Bool' type.
> The latter was probably chosen in that special syntax to avoid
> conflicts during "C" language evolution?

Yes.  The tradition in C has been that added keywords have had this 
_Form, since that type of identifier is reserved.  Thus between C99 
(when _Bool was added) and C17, the type was named "_Bool", and the 
header <stdboolh> contained:

	#define bool _Bool
	#define true 1
	#define false 0

For C23, it was decided that after 20-odd years people should be using 
the standard C boolean types, and thus the type was renamed "bool" (with 
"_Bool" kept as a synonym), and "true" and "false" became keywords. 
<stdbool.h> is now basically empty (and unnecessary) in C23 mode, but of 
course still exists for compatibility.

> How do regular "C" programmers handle that multitude of boolean
> types; ranging from use of 'int', over own "bool" types, then
> '_Bool', and now 'bool'? Since it's a very basic type it looks
> like you need hard transitions in evolution of your "C" code?
> 

For anything that is not hampered by ancient legacy code, you use :

	#include <stdbool.h>

	bool a = false;
	bool b = true;

That applies from C99 up to and including C23 - though if your code is 
definitely C23-only, you can happily omit the #include.

For pre-C99 code that uses home-made boolean types, it is common in 
reusable code (such as libraries) for the types and everything else to 
be prefixed - "MYLIB_boolean", etc.  But some code might use the names 
"bool", "true" and "false" with their own definitions.  If those are 
#define definitions, the code will probably work much as before though 
it is technically UB, but if they are typedefs, enums, etc., they cannot 
be compiled as C23.