Groups | Search | Server Info | Login | Register
Groups > comp.lang.c > #397337
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: gcc and 'include' |
| Date | 2026-03-31 13:56 -0700 |
| Organization | None to speak of |
| Message-ID | <87mrznu39c.fsf@example.invalid> (permalink) |
| References | (10 earlier) <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> |
Bart <bc@freeuk.com> writes:
> On 31/03/2026 02:07, Keith Thompson wrote:
>> Bart <bc@freeuk.com> 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 */
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar
gcc and 'include' Bart <bc@freeuk.com> - 2026-03-26 22:36 +0000
Re: gcc and 'include' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-26 16:12 -0700
Re: gcc and 'include' Bart <bc@freeuk.com> - 2026-03-27 10:55 +0000
Re: gcc and 'include' David Brown <david.brown@hesbynett.no> - 2026-03-27 13:49 +0100
Re: gcc and 'include' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-27 10:51 -0700
Re: gcc and 'include' Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-27 21:27 +0000
Re: gcc and 'include' Bart <bc@freeuk.com> - 2026-03-27 22:05 +0000
Re: gcc and 'include' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-27 17:03 -0700
Re: gcc and 'include' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-03-28 05:10 +0100
Re: gcc and 'include' Michael S <already5chosen@yahoo.com> - 2026-03-28 20:37 +0300
Re: gcc and 'include' Bart <bc@freeuk.com> - 2026-03-28 18:33 +0000
Re: gcc and 'include' antispam@fricas.org (Waldek Hebisch) - 2026-03-29 00:53 +0000
Re: gcc and 'include' Bart <bc@freeuk.com> - 2026-03-29 22:37 +0100
Re: gcc and 'include' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-30 05:33 -0700
Re: gcc and 'include' Bart <bc@freeuk.com> - 2026-03-30 14:42 +0100
Re: gcc and 'include' Michael S <already5chosen@yahoo.com> - 2026-03-30 16:53 +0300
Re: gcc and 'include' Bart <bc@freeuk.com> - 2026-03-30 18:11 +0100
Re: gcc and 'include' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-30 08:27 -0700
Re: gcc and 'include' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-30 11:54 -0700
Re: gcc and 'include' Bart <bc@freeuk.com> - 2026-03-30 21:54 +0100
Re: gcc and 'include' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-30 18:07 -0700
Re: gcc and 'include' Bart <bc@freeuk.com> - 2026-03-31 11:39 +0100
Re: gcc and 'include' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-31 13:56 -0700
Re: gcc and 'include' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-06 20:56 -0700
Re: gcc and 'include' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-06 23:12 -0700
Re: gcc and 'include' James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-03-30 21:06 -0400
Re: gcc and 'include' David Brown <david.brown@hesbynett.no> - 2026-03-29 11:24 +0200
Re: gcc and 'include' Bart <bc@freeuk.com> - 2026-03-29 12:44 +0100
Re: gcc and 'include' David Brown <david.brown@hesbynett.no> - 2026-03-31 15:57 +0200
Re: gcc and 'include' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-30 07:20 -0700
Re: gcc and 'include' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-30 05:07 -0700
Re: gcc and 'include' Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-27 00:25 +0000
Re: gcc and 'include' Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-30 07:13 +0000
Re: gcc and 'include' Andrey Tarasevich <noone@noone.net> - 2026-03-30 07:54 -0700
Re: gcc and 'include' Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-31 01:46 +0000
Re: gcc and 'include' antispam@fricas.org (Waldek Hebisch) - 2026-03-31 05:28 +0000
Re: gcc and 'include' Michael S <already5chosen@yahoo.com> - 2026-03-27 04:10 +0300
Re: gcc and 'include' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-26 19:08 -0700
Re: gcc and 'include' Michael S <already5chosen@yahoo.com> - 2026-03-27 16:47 +0300
Re: gcc and 'include' David Brown <david.brown@hesbynett.no> - 2026-03-27 16:43 +0100
Re: gcc and 'include' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-27 09:03 -0700
Re: gcc and 'include' Michael S <already5chosen@yahoo.com> - 2026-03-29 11:46 +0300
Re: gcc and 'include' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-30 08:19 -0700
Re: gcc and 'include' Michael S <already5chosen@yahoo.com> - 2026-03-30 20:08 +0300
Re: gcc and 'include' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-31 00:26 -0700
Re: gcc and 'include' Michael S <already5chosen@yahoo.com> - 2026-03-31 11:27 +0300
Re: gcc and 'include' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-07 09:45 -0700
Re: gcc and 'include' Andrey Tarasevich <noone@noone.net> - 2026-03-28 10:25 -0700
Re: gcc and 'include' Michael S <already5chosen@yahoo.com> - 2026-03-29 10:37 +0300
Re: gcc and 'include' David Brown <david.brown@hesbynett.no> - 2026-03-29 11:30 +0200
Re: gcc and 'include' Andrey Tarasevich <noone@noone.net> - 2026-03-29 07:22 -0700
Re: gcc and 'include' James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-03-29 13:56 -0400
Re: gcc and 'include' Michael S <already5chosen@yahoo.com> - 2026-03-29 21:39 +0300
Re: gcc and 'include' James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-03-29 20:08 -0400
Re: gcc and 'include' Bart <bc@freeuk.com> - 2026-03-30 01:58 +0100
Re: gcc and 'include' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-30 07:59 -0700
Re: gcc and 'include' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-26 19:06 -0700
Re: gcc and 'include' Bart <bc@freeuk.com> - 2026-03-27 16:20 +0000
Re: gcc and 'include' David Brown <david.brown@hesbynett.no> - 2026-03-27 18:07 +0100
Re: gcc and 'include' James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-03-28 18:48 -0400
Re: gcc and 'include' Andrey Tarasevich <noone@noone.net> - 2026-03-27 22:38 -0700
Re: gcc and 'include' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-28 00:30 -0700
Re: gcc and 'include' Andrey Tarasevich <noone@noone.net> - 2026-03-29 16:15 -0700
Re: gcc and 'include' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-30 00:41 -0700
csiph-web