Re: "A diagram of C23 basic types"

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.

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

Now memcpy is a bad example.

But imagine some large API.  Your program uses, say 5% of
the API. Somewhere in the API is a utility function you're
not interested in, It does something involving the API,
and some type you don't care about.

Why should the type be revealed to your translation unit?

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.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca