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?  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 would break existing code, for example any code that includes
<string.h> and refers to the name "size_t" without include <stddef.h>

That's a tremendous barrier to overcome for the sake of some
slight theoretical cleanliness -- and it would be inconvenient
for programmers.

I'll note that the standard doesn't have a general rule that each
header must define all type names that it uses.  Instead, for each
header, it specifies what it must define.  The rationale for having
<string.h> define size_t is obviously that it declares functions
that use it, but a programmer can simply assume that <string.h>
defines size_t because the standard says it does.

If your proposal had been followed in 1989, I probably wouldn't
have much of a problem with it.  It's too late now.

All this confusion is the result of the fact that using parts of the
standard library by including header files (with include guards,
reserved identifiers as macros, and so on) is a rather ugly hack.
I would oppose tweaks to that hack that break existing code *unless*
there's an overall redesign that gives us something better (maybe
some kind of module system).  Of course any such redesign would
have to coexist with the existing hack.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */