Deutsch   English   Français   Italiano  
<vsn0dm$2al86$1@paganini.bofh.team>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!news.tomockey.net!news.samoylyk.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: Thu, 3 Apr 2025 22:00:24 -0000 (UTC)
Organization: To protect and to server
Message-ID: <vsn0dm$2al86$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>
Injection-Date: Thu, 3 Apr 2025 22:00:24 -0000 (UTC)
Injection-Info: paganini.bofh.team; logging-data="2446598"; 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: 2360
Lines: 31

Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> Kaz Kylheku <643-408-1753@kylheku.com> writes:
> 
> [some symbols are defined in more than one header]
> 
>> (In my opinion, things would be better if headers were not allowed
>> to behave as if they include other headers, or provide identifiers
>> also given in other heards.  Not in ISO C, and not in POSIX.
>> Every identifier should be declared in exactly one home header,
>> and no other header should provide that definition.  [...])
> 
> 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.

> Similarly for NULL for any function that has defined
> behavior on some cases of arguments that include NULL.

Why?  There are many ways to produce null pointers.  And fact that
a function had defined behavior for null pointers does not mean
that users will need null pointers.

> No doubt
> there are other compelling examples.

Do not look compelling at all.

-- 
                              Waldek Hebisch