| 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.