Sujet : Re: "A diagram of C23 basic types"
De : janis_papanagnou+ng (at) *nospam* hotmail.com (Janis Papanagnou)
Groupes : comp.lang.cDate : 03. Apr 2025, 22:19:23
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vsmu0s$1lh9l$1@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10 11 12
User-Agent : Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
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.
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. (But we're speaking about "C" so it's probably
pointless to discuss that from a more fundamental perspective...)
The practical "C" approach was always to just include what you need
(and don't make ones mind about "C" language design [or mis-design]).
Janis