Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: "A diagram of C23 basic types" Date: Mon, 07 Apr 2025 14:19:39 -0700 Organization: None to speak of Lines: 53 Message-ID: <87a58rd5zo.fsf@nosuchdomain.example.com> References: <87y0wjaysg.fsf@gmail.com> <20250402113624.693@kylheku.com> <86o6xdhorr.fsf@linuxsc.com> <87ikngd7jg.fsf@nosuchdomain.example.com> MIME-Version: 1.0 Content-Type: text/plain Injection-Date: Mon, 07 Apr 2025 23:19:40 +0200 (CEST) Injection-Info: dont-email.me; posting-host="2714e7df686d80d73a1feebaa5e76a7a"; logging-data="687569"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19j1A783KALMRgkmj413qtA" User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:P9y1P/ANrhJ6bxxylaYaLFzs64k= sha1:BcPtkRIRyPyVK9Ech1BgVmxgCf8= Bytes: 3887 antispam@fricas.org (Waldek Hebisch) writes: > Keith Thompson wrote: >> antispam@fricas.org (Waldek Hebisch) writes: >>> Tim Rentsch 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 >> 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. That would break existing code, for example any code that includes and refers to the name "size_t" without include That's a tremendous barrier to overcome for the sake of some slight theoretical cleanliness -- and it would be inconvenient for programmers. I'll note that the standard doesn't have a general rule that each header must define all type names that it uses. Instead, for each header, it specifies what it must define. The rationale for having define size_t is obviously that it declares functions that use it, but a programmer can simply assume that defines size_t because the standard says it does. If your proposal had been followed in 1989, I probably wouldn't have much of a problem with it. It's too late now. All this confusion is the result of the fact that using parts of the standard library by including header files (with include guards, reserved identifiers as macros, and so on) is a rather ugly hack. I would oppose tweaks to that hack that break existing code *unless* there's an overall redesign that gives us something better (maybe some kind of module system). Of course any such redesign would have to coexist with the existing hack. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com void Void(void) { Void(); } /* The recursive call of the void */