Re: "A diagram of C23 basic types"

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.