Deutsch   English   Français   Italiano  
<86ecxv9lkx.fsf@linuxsc.com>

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

Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: "A diagram of C23 basic types"
Date: Mon, 14 Apr 2025 01:46:54 -0700
Organization: A noiseless patient Spider
Lines: 27
Message-ID: <86ecxv9lkx.fsf@linuxsc.com>
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> <20250402232443.00003a7d@yahoo.com> <vslilm$8mfb$1@dont-email.me> <vsm05b$k0b7$1@dont-email.me> <85y0whjdw3.fsf@nosuchdomain.example.com> <vsmlc4$1c39t$1@dont-email.me> <85ldshjb72.fsf@nosuchdomain.example.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Mon, 14 Apr 2025 10:46:54 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="94f07fe53fa8e4a0f6a79bf0296fa912";
	logging-data="877446"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/pKnx0kPIsW3PQPok0dcV+2NAyDPaafQQ="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:Y6p22d5qEmLHv04QvsM5BOTJSS4=
	sha1:aGvo3lhMcbOh1w2AVsJq7l4Djpw=
Bytes: 2636

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

[considering ways of importing all headers defined as part
 of the standard library]

> My point is that, as far as I'm aware, nobody has implemented
> "implicitly include all the standard headers", either as a compiler
> option or as a wrapper script.  I'm sure somebody has (I could do
> it in a few minutes), but it's just not something that programmers
> appear to want.
>
> Of course part of the motivation for *not* wanting this is that
> it results in non-portable code, and if it were standardized that
> wouldn't be an issue.
>
> And if it were standardized, <assert.h> would raise some issues,
> since NDEBUG needs to be defined or not defined before including it.

Not really a problem, since if a different choice for NDEBUG were
desired then it could be #define'd or #undef'ed, as appropriate,
followed by another #include <assert.h>.

That said, it's hard to imagine many people wanting such a thing.
It's a very rare translation unit that needs or even wants access
to symbols defined in every header in the standard library.  And
it flies in the face of the common practice of #include'ing only
those headers that are actually needed in each translation unit.