Re: "A diagram of C23 basic types"

antispam@fricas.org (Waldek Hebisch) writes:

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?

>
Cleanliness of definitions?  Consistency?

Convenience of clients of the interface:  less work and very
little downside.

Existing practice:  module systems have been around since the mid
1970s.  Typically a module interface also makes available names of
all types used by functions in the interface.

Fragment that you
replaced by [...] contained a proposal:
>

Every identifier should be declared in exactly one home header,
and no other header should provide that definition.

>
That would be pretty clean and consistent rule:  if you need some
standard symbol, then you should include corresponding header.

That is a simple rule, but not the only simple rule.  The C standard
library consistently follows the simple rule that headers define
names for all the types used by the interface, so just #include'ing
the header means all types used by those interface functions are
available.  As far as clients are concerned, that rule is simpler.

Tim claimed that this in not practical.  Clearly C standard
changed previous practice about headers,

I believe that's not true, but certainly it is not /clearly/ true.
A lot of time passed between 1978, when K&R was published, and 1989,
when the first C standard was ratified.  No doubt the C standard
unified different practices among many existing C implementations,
but it is highly likely that some of them anticipated the rules that
would be ratified in the C standard.

so existing practice is _not_ a practical problem with adapting
such proposal.

Common practice for module definitions, across many languages, is to
make available names for the types used by interfaces that are
supplied by the module.

With current standard and practice one frequently needs symbols
from several headers,

Yes but there is a key difference.  Different headers correspond to
major areas of interface.  It is natural, for example to expect the
functions of <stdio.h> and <string.h> to be in separate headers.
That expectation does not extend to names like size_t, which plays a
support role rather than a primary role.

so "convenience" is also not a practival problem with such
proposal.

Nonsense.  Having to do a separate #include for size_t would be a
pain in the ass.

People not interested in clean name space can
define private "all.h" which includes all standard C headers
and possibly other things that they need, so for them overhead
is close to zero.

This point of view strikes me as the tail wagging the dog.  The ISO
C standard made a decision to make a few very commonly used names
available from several different headers.  I'm not aware of any
practical problems that have been caused by that decision, and I
don't remember hearing anyone object to it until just very recently
by just a few people.  The idea that any name defined in the
standard library should be available in only one header gives the
impression of an intellectual suggestion untethered to any practical
experience.