Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: "A diagram of C23 basic types"
Date: Wed, 30 Apr 2025 08:37:54 -0700
Organization: A noiseless patient Spider
Lines: 60
Message-ID: <8634dp8xt9.fsf@linuxsc.com>
References: <87y0wjaysg.fsf@gmail.com> <vsj1m8$1f8h2$1@dont-email.me> <vsj2l9$1j0as$1@dont-email.me> <vsjef3$1u4nk$1@dont-email.me> <vsjg6t$20pdb$1@dont-email.me> <vsjjd1$23ukt$1@dont-email.me> <vsjkvb$25mtg$1@dont-email.me> <vsjlkq$230a5$2@dont-email.me> <vsjs5k$2bfc5$2@dont-email.me> <vsjvgu$2fpp1$1@dont-email.me> <20250402113624.693@kylheku.com> <86o6xdhorr.fsf@linuxsc.com> <vsn0dm$2al86$1@paganini.bofh.team>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Wed, 30 Apr 2025 17:37:54 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="9e13ded7da6da949b3ed5dcd67cb8b30";
	logging-data="590317"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+CbmB1U4HLqUVwzIcKKcyUsSdMTPU5QNw="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:7FYCT8UDjFuy/wcbcT9UShsCx4M=
	sha1:A1MQly9SaL6ji3RLioOOqGjXeAQ=
Bytes: 3784

antispam@fricas.org (Waldek Hebisch) writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> 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.
>
> Why?

Because, in many cases or most cases, when a particular interface is
used, there will be a need to declare variables of a type used in the
interface (either a parameter type or the return type), or to use
such types in other ways (casting, for example).  Not defining those
type names makes more work for the client.

> One can use a type without a name for such type.

What you mean is it's possible to produce values of such types
without needing to use the name of the type.  In some cases that's
true, but often there are other needs that are not addressed by
that possibility, as mentioned in the last paragraph.  Furthermore
it doesn't cover cases of derived types, such as size_t *.

>> Similarly for NULL for any function that has defined
>> behavior on some cases of arguments that include NULL.
>
> Why?  There are many ways to produce null pointers.

The macro NULL is used for purposes of documentation.  Of course a
simple 0 (perhaps casted to an appropriate type) could be used
instead, but that defeats the purpose of using NULL.

> And fact that
> a function had defined behavior for null pointers does not mean
> that users will need null pointers.

No guarantee, but there is a reasonable likelihood.  It's more
convenient for the client if such things are always provided.

>> No doubt
>> there are other compelling examples.
>
> Do not look compelling at all.

Clearly the people who wrote the ISO C standard feel differently.
I agree with their judgment.  And I haven't seen any argument
that a different judgment should prevail, not counting the silly
circular argument offered by another poster.