Path: csiph.com!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: "A diagram of C23 basic types" Date: Mon, 14 Apr 2025 05:46:21 -0700 Organization: A noiseless patient Spider Lines: 46 Message-ID: <861ptuap2a.fsf@linuxsc.com> References: <87y0wjaysg.fsf@gmail.com> <20250402113624.693@kylheku.com> <86o6xdhorr.fsf@linuxsc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Mon, 14 Apr 2025 14:46:25 +0200 (CEST) Injection-Info: dont-email.me; posting-host="94f07fe53fa8e4a0f6a79bf0296fa912"; logging-data="1372082"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19WL7YYYjUk114udNVNdmAW+h1mOHm9QSw=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:yXCQDbZ4cn00kzkm3kGQmnevG0Q= sha1:iliFjvCNsLtsgQ/i8HpbFhCS7Aw= Xref: csiph.com comp.lang.c:392505 Janis Papanagnou writes: > On 03.04.2025 06:06, Tim Rentsch 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. Similarly for NULL for any function that has defined >> behavior on some cases of arguments that include NULL. No doubt >> there are other compelling examples. > > I think that all that's said above (by Kaz and you) is basically > correct. An interesting statement, considering that Kaz's comment and my comment are mutually contradictory. > Obviously [to me] it is that 'size_t' and 'NULL' are so fundamental > entities (a standard type and a standard pointer constant literal) > that such items should have been inherent part of the "C" language, > and not #include'd. You haven't really given any reason why you think so. You're just substituting one subjective property ("fundamental") for another (should be part of the language proper). In either case you're doing nothing more than saying "I think it should be this way". I am guided by Tony Hoare's advice about programming languages: a programming language should include only those elements that will be used by every (nontrivial) program written in the language. Neither size_t nor NULL is needed to pass this test. Furthermore, in those cases where they are needed, they come along with no effort by virtue of being part of the header(s) used by the program. Since they are not always necessary, and since no effort is needed to make use of them in those situations where they are useful, there is no reason to have them be part of the core language.