Path: csiph.com!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:12:40 -0700
Organization: A noiseless patient Spider
Lines: 61
Message-ID: <867c318yzb.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> <87ikngd7jg.fsf@nosuchdomain.example.com> <20250406210339.382@kylheku.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Wed, 30 Apr 2025 17:12:44 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="9e13ded7da6da949b3ed5dcd67cb8b30"; logging-data="590317"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18inKAKE4DCg3WT1XUWG4fXWNunU+ob6Lc="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:9bGjGNNDImuZH7fLP+jQNmtzO/E= sha1:CwOVZY23RhnHg74zHX/QRfvNw54=
Xref: csiph.com comp.lang.c:393087

Kaz Kylheku <643-408-1753@kylheku.com> writes:

> On 2025-04-07, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>
>> antispam@fricas.org (Waldek Hebisch) writes:
>>
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>
>> [...]
>>
>>>> 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?  One can use a type without a name for such type.
>>
>> Convenience and existing practice.  Sure, an implementation of
>> <string.h> could provide a declaration of memcpy() without making
>> size_t visible, but what would be the point?
>
> Ther eis a point to such a discipline;  you get ultra squeaky clean
> modules whose header files define only their contribution to
> the program, and do not transitively reveal any of the identifiers
> from their dependencies.

That's a circular argument.  If a header is designed so it doesn't
define type names like size_t, then #include'ing it won't define
those names.  It is equally true that if a header is designed so
it does define such type names then #include'ing it will define
those names.

Incidentally, calling it "squeaky clean" is meaningless;  just
more circular reasoning.

> In large programs, this clean practice can can help prevent
> clashes.

That doesn't apply to headers defined by the ISO C standard,
which is the topic under discussion.

> [...]
>
> Using memcpy as an example, it could be declared as
>
>   void *memcpy(void * restrict d, const void * restrict s,
>                __size_t size);
>
> size_t is not revealed, but a private type __size_t.
>
> To get __size_t, some private header is included <sys/priv_types.h>
> or whatever.
>
> The <stddef.h> header just includes that one and typedefs __size_t
> size_t (if it were to work that way).
>
> A system vendor which provides many API's and has the privilege of
> being able to use the __* space could do things like this.

An implicit logical fallacy.  Just because something /can/ be done
doesn't mean it /should/ be done.