Re: "A diagram of C23 basic types"

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

On 03.04.2025 06:06, Tim Rentsch wrote:
>

Kaz Kylheku <643-408-1753@kylheku.com> writes:
>
[some symbols are defined in more than one header]
>

(In my opinion, things would be better if headers were not allowed
to behave as if they include other headers, or provide identifiers
also given in other heards.  Not in ISO C, and not in POSIX.
Every identifier should be declared in exactly one home header,
and no other header should provide that definition.  [...])

>
Not always practical.  A good example is the type size_t.  If a
function takes an argument of type size_t, then the symbol size_t
should be defined, no matter which header the function is being
declared in.  Similarly for NULL for any function that has defined
behavior on some cases of arguments that include NULL.  No doubt
there are other compelling examples.

>
I think that all that's said above (by Kaz and you) is basically
correct.

An interesting statement, considering that Kaz's comment and my
comment are mutually contradictory.

Obviously [to me] it is that 'size_t' and 'NULL' are so fundamental
entities (a standard type and a standard pointer constant literal)
that such items should have been inherent part of the "C" language,
and not #include'd.

You haven't really given any reason why you think so.  You're just
substituting one subjective property ("fundamental") for another
(should be part of the language proper).  In either case you're
doing nothing more than saying "I think it should be this way".

I am guided by Tony Hoare's advice about programming languages:  a
programming language should include only those elements that will be
used by every (nontrivial) program written in the language.  Neither
size_t nor NULL is needed to pass this test.  Furthermore, in those
cases where they are needed, they come along with no effort by
virtue of being part of the header(s) used by the program.  Since
they are not always necessary, and since no effort is needed to make
use of them in those situations where they are useful, there is no
reason to have them be part of the core language.