Path: ...!feeds.phibee-telecom.net!2.eu.feeder.erje.net!feeder.erje.net!newsfeed.bofh.team!paganini.bofh.team!not-for-mail
From: antispam@fricas.org (Waldek Hebisch)
Newsgroups: comp.lang.c
Subject: Re: "A diagram of C23 basic types"
Date: Mon, 7 Apr 2025 18:31:03 -0000 (UTC)
Organization: To protect and to server
Message-ID: <vt15l5$3e57a$1@paganini.bofh.team>
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>
Injection-Date: Mon, 7 Apr 2025 18:31:03 -0000 (UTC)
Injection-Info: paganini.bofh.team; logging-data="3609834"; posting-host="WwiNTD3IIceGeoS5hCc4+A.user.paganini.bofh.team"; mail-complaints-to="usenet@bofh.team"; posting-account="9dIQLXBM7WM9KzA+yjdR4A";
User-Agent: tin/2.6.2-20221225 ("Pittyvaich") (Linux/6.1.0-9-amd64 (x86_64))
X-Notice: Filtered by postfilter v. 0.9.3
Bytes: 2850
Lines: 35

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.

Tim claimed that this in not practical.  Clearly C standard changed
previous practice about headers, so existing practice is _not_
a practical problem with adapting such proposal.  With current
standard and practice one frequently needs symbols from several
headers, so "convenience" is also not a practival problem with
such proposal.  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.

-- 
                              Waldek Hebisch