Path: csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: gcc and 'include' Date: Tue, 31 Mar 2026 13:56:31 -0700 Organization: None to speak of Lines: 117 Message-ID: <87mrznu39c.fsf@example.invalid> References: <10q4ceb$38i2d$1@dont-email.me> <87ikaiw5g0.fsf@example.invalid> <10q5nnr$3l3lc$1@dont-email.me> <10q6snp$2nka$5@dont-email.me> <10q6uv4$419b$1@dont-email.me> <20260328203718.00005c70@yahoo.com> <10q96uf$rjbn$1@dont-email.me> <10q9t6d$2p36t$1@paganini.bofh.team> <10qc632$1uds9$1@dont-email.me> <86mrzp1oql.fsf@linuxsc.com> <10qdujq$2g7uj$1@dont-email.me> <87v7edtafm.fsf@example.invalid> <10qenu5$2q4nh$1@dont-email.me> <87qzp0u7py.fsf@example.invalid> <10qg89b$38lit$1@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain Injection-Date: Tue, 31 Mar 2026 20:56:32 +0000 (UTC) Injection-Info: dont-email.me; posting-host="43a39da5ea826f3cab717fc4bda0b1e9"; logging-data="3841439"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/SYdLO+Eij2Q3NR6XW9sIl" User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:umQMgp9gqxjtA1goK3/D38sJf5Q= sha1:upq5PZdouZ34OrxjZVgsf+jqtp8= Xref: csiph.com comp.lang.c:397337 Bart writes: > On 31/03/2026 02:07, Keith Thompson wrote: >> Bart writes: >>> On 30/03/2026 19:54, Keith Thompson wrote: >> [...] >>>> You're complaining about gcc being lax, not about the C language >>>> being lax. >>> >>> It's both. Example: >>> >>> signed char* p; >>> unsigned char* q; >>> p = q; >>> >>> This compiles OK with no options. But should it; what does the >>> language say about it? >> As I think you already know, that's a constraint violation, >> requiring a diagnostic. > > But apparently it doesn't require it to fail the compilation. Apparently? ISO C requires a diagnostic for any translation unit that contains a violation of any syntax rule or constraint. It never requires compilation to fail, with the sole exception of the #error directive. Did you really not know that? >>> Another example: >>> >>> int F(){} >>> >>> Here not even -Wextra touches it. I need -Wpedantic, which tells me a >>> lot about C! >> "gcc -Wpedantic" doesn't complain about that. There is no syntax >> error and no constraint violation, so the language does not require >> a diagnostic. >> If you have a point, feel free to make it more clearly. > > OK, you suggested that it was a compiler being lax, not the language. My point was that your example did not demonstrate that the language is lax. gcc by default does not generate all the diagnostics that are required by the language. Observing that fact says nothing about the language. > Here, allowing such code to be written IS being lax. And in the above > example, the language allowing the compiler to ignore the error or to > only warn, is also being lax. I don't disagree. I would have preferred a requirement that any translation unit that violates a syntax rule or constraing must be rejected. Most compilers would undoubtedly have provided options to turn fatal errors into warnings in a non-conforming mode. "int F(){}" is probably a better example of the point you were making than the example you provided upthread (which I'm too lazy to look up). > But I expect that you will now redefine 'lax', or 'laxity' in such a > way that the language cannot ever be accused of being it. It's all > under control! Do not put words in my mouth. Do not pretend that I have every said or implied that C is flawless. > So a language may require a diagnostic but leaves it up to the > compiler as to how severely it is reported, if at all. The language requires diagnostic for certain errors. It does not specify whether those diagnostics are fatal or not. It does not permit a conforming compiler to fail to produce a required diagnostic. A non-conforming compiler can obviously do anythiung it likes; it would be absurd for the standard to try to impose requirements on implementations that do not conform to it. You know this, but you pretend not to. > Or the language specifies that running into the final '}' of a > non-void function is UB, thereby washing its hands of it. No, it specifies that if a non-void function doesn't return a value (falls off the end without executing a return statement), attempting to use that value has undefined behavior. Yes, this is lax. The historical reasons for this have been discussed at great length. Any language change that would require a diagnostic for "int F(void){}" would require more compile-time analysis than is currently required. I would support adding such a requirement to a new edition of the standard. I'm not aware of any proposal to do so. For example: int F(void) { if (time(NULL) > 0) { return 1; } } Last time this was discussed here, I suggested adopting something similar to C#'s rules in this area. > However the end result is that people CAN write sloppy code, and that > in my book is the language being 'lax'. Again, I don't disagree -- with the proviso that it's not possible for any non-trivial language to forbid all sloppy code. > (Both of these examples will fail compilation in my language: [snip] I might be willing to discuss your language if you talked about it in comp.lang.misc. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com void Void(void) { Void(); } /* The recursive call of the void */