Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #382072 > unrolled thread
| Started by | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| First post | 2024-02-08 01:01 -0300 |
| Last post | 2024-02-10 22:21 -0800 |
| Articles | 3 on this page of 83 — 12 participants |
Back to article view | Back to comp.lang.c
Is C ready to become a safer language? Thiago Adams <thiago.adams@gmail.com> - 2024-02-08 01:01 -0300
Re: Is C ready to become a safer language? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-08 04:40 +0000
Re: Is C ready to become a safer language? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-08 05:00 +0000
Re: Is C ready to become a safer language? Thiago Adams <thiago.adams@gmail.com> - 2024-02-08 09:20 -0300
Re: Is C ready to become a safer language? bart <bc@freeuk.com> - 2024-02-08 17:02 +0000
Re: Is C ready to become a safer language? Thiago Adams <thiago.adams@gmail.com> - 2024-02-08 14:17 -0300
Re: Is C ready to become a safer language? Thiago Adams <thiago.adams@gmail.com> - 2024-02-08 14:19 -0300
Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-08 09:57 -0800
Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-08 09:45 -0800
Re: Is C ready to become a safer language? Thiago Adams <thiago.adams@gmail.com> - 2024-02-08 14:56 -0300
Re: Is C ready to become a safer language? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-08 04:58 +0000
Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-07 21:33 -0800
Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-07 20:59 -0800
Re: Is C ready to become a safer language? David Brown <david.brown@hesbynett.no> - 2024-02-08 09:17 +0100
Re: Is C ready to become a safer language? Thiago Adams <thiago.adams@gmail.com> - 2024-02-08 09:48 -0300
Re: Is C ready to become a safer language? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-08 14:42 +0000
Re: Is C ready to become a safer language? David Brown <david.brown@hesbynett.no> - 2024-02-08 16:25 +0100
Re: Is C ready to become a safer language? Thiago Adams <thiago.adams@gmail.com> - 2024-02-08 13:15 -0300
Re: Is C ready to become a safer language? David Brown <david.brown@hesbynett.no> - 2024-02-08 21:42 +0100
Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-08 08:04 -0800
Re: Is C ready to become a safer language? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-08 16:14 +0000
Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-08 08:32 -0800
Re: Is C ready to become a safer language? David Brown <david.brown@hesbynett.no> - 2024-02-09 08:19 +0100
Re: Is C ready to become a safer language? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-09 07:46 +0000
Re: Is C ready to become a safer language? David Brown <david.brown@hesbynett.no> - 2024-02-09 09:33 +0100
Re: Is C ready to become a safer language? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-09 10:03 +0000
Re: Is C ready to become a safer language? David Brown <david.brown@hesbynett.no> - 2024-02-09 11:17 +0100
Re: Is C ready to become a safer language? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-09 10:24 +0000
Re: Is C ready to become a safer language? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-09 11:24 +0000
Re: Is C ready to become a safer language? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-09 13:28 +0000
Re: Is C ready to become a safer language? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-09 14:04 +0000
Re: Is C ready to become a safer language? David Brown <david.brown@hesbynett.no> - 2024-02-09 15:03 +0100
ustent on that. Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-09 16:01 +0000
Re: ustent on that. David Brown <david.brown@hesbynett.no> - 2024-02-09 18:00 +0100
Re: ustent on that. Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-10 01:20 +0000
Re: Is C ready to become a safer language? bart <bc@freeuk.com> - 2024-02-09 12:45 +0000
Re: Is C ready to become a safer language? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-09 13:01 +0000
Re: Is C ready to become a safer language? David Brown <david.brown@hesbynett.no> - 2024-02-09 15:08 +0100
Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-09 08:48 -0800
Re: Is C ready to become a safer language? David Brown <david.brown@hesbynett.no> - 2024-02-09 08:14 +0100
Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-09 08:28 -0800
Re: Is C ready to become a safer language? David Brown <david.brown@hesbynett.no> - 2024-02-09 20:15 +0100
Re: Is C ready to become a safer language? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-10 02:28 -0800
Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-10 16:15 -0800
Re: Is C ready to become a safer language? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-10 23:22 -0800
Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-11 00:12 -0800
Re: Is C ready to become a safer language? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-11 23:48 -0800
Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-18 15:28 -0800
Re: Is C ready to become a safer language? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-23 10:35 -0700
Re: Is C ready to become a safer language? Richard Kettlewell <invalid@invalid.invalid> - 2024-02-08 15:37 +0000
Re: Is C ready to become a safer language? Thiago Adams <thiago.adams@gmail.com> - 2024-02-08 13:25 -0300
Re: Is C ready to become a safer language? bart <bc@freeuk.com> - 2024-02-08 16:30 +0000
Re: Is C ready to become a safer language? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-09 17:59 -0800
Re: Is C ready to become a safer language? bart <bc@freeuk.com> - 2024-02-10 20:22 +0000
Re: Is C ready to become a safer language? Richard Harnden <richard.nospam@gmail.invalid> - 2024-02-10 21:30 +0000
Re: Is C ready to become a safer language? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-10 21:49 +0000
Re: Is C ready to become a safer language? Thiago Adams <thiago.adams@gmail.com> - 2024-02-10 20:44 -0300
Re: Is C ready to become a safer language? David Brown <david.brown@hesbynett.no> - 2024-02-11 13:06 +0100
Re: Is C ready to become a safer language? Thiago Adams <thiago.adams@gmail.com> - 2024-02-11 15:43 -0300
Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-11 13:33 -0800
Re: Is C ready to become a safer language? David Brown <david.brown@hesbynett.no> - 2024-02-12 11:32 +0100
Re: Is C ready to become a safer language? bart <bc@freeuk.com> - 2024-02-11 00:02 +0000
Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-10 17:39 -0800
Re: Is C ready to become a safer language? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-11 02:46 +0000
Re: Is C ready to become a safer language? bart <bc@freeuk.com> - 2024-02-11 12:24 +0000
Re: Is C ready to become a safer language? David Brown <david.brown@hesbynett.no> - 2024-02-11 15:06 +0100
Re: Is C ready to become a safer language? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-11 18:32 +0000
Re: Is C ready to become a safer language? David Brown <david.brown@hesbynett.no> - 2024-02-11 13:15 +0100
Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-10 16:31 -0800
Re: Is C ready to become a safer language? Thiago Adams <thiago.adams@gmail.com> - 2024-02-11 15:57 -0300
Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-11 13:47 -0800
Re: Is C ready to become a safer language? vallor <vallor@cultnix.org> - 2024-02-11 00:40 +0000
Re: Is C ready to become a safer language? bart <bc@freeuk.com> - 2024-02-11 01:06 +0000
Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-10 17:51 -0800
Re: Is C ready to become a safer language? David Brown <david.brown@hesbynett.no> - 2024-02-11 13:27 +0100
Re: Is C ready to become a safer language? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-10 19:54 -0800
Re: Is C ready to become a safer language? vallor <vallor@cultnix.org> - 2024-02-13 06:22 +0000
Re: Is C ready to become a safer language? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-11 11:01 +0000
Re: Is C ready to become a safer language? Richard Harnden <richard.nospam@gmail.invalid> - 2024-02-11 11:31 +0000
Re: Is C ready to become a safer language? bart <bc@freeuk.com> - 2024-02-11 12:38 +0000
Re: Is C ready to become a safer language? Richard Harnden <richard.nospam@gmail.invalid> - 2024-02-11 13:23 +0000
Re: Is C ready to become a safer language? bart <bc@freeuk.com> - 2024-02-11 14:17 +0000
Re: Is C ready to become a safer language? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-10 22:21 -0800
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
| From | Richard Harnden <richard.nospam@gmail.invalid> |
|---|---|
| Date | 2024-02-11 13:23 +0000 |
| Message-ID | <uqahnm$vsal$1@dont-email.me> |
| In reply to | #382326 |
On 11/02/2024 12:38, bart wrote:
> On 11/02/2024 11:31, Richard Harnden wrote:
>> On 11/02/2024 11:01, Malcolm McLean wrote:
>>> On 11/02/2024 00:40, vallor wrote:
>>>> ("Is there anyone here who thinks that" bart's continuous
>>>> complaining about options to gcc deserve any merit?)
>>>>
>>> The compiler should be invoked with
>>>
>>> gcc foo.c
>>>
>>
>> As a first stab, I'd use:
>>
>> gcc -std=c11 -pedantic -W -Wall -Wextra -Werror foo.c
>>
>> and try very hard to fix any/all warnings.
>
>
> That sounds like an incredibly slow and painful way to code.
>
> During development, you are adding, modifying, commenting, uncommenting
> and tearing down code all the time.
>
> C already requires you to dot all the Is and cross all the Ts because of
> its syntax and type needs. Why make the job even harder?
Fixing things early /is/ easier. YMMobviouslyV.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-02-11 14:17 +0000 |
| Message-ID | <uqaktl$10e97$1@dont-email.me> |
| In reply to | #382332 |
On 11/02/2024 13:23, Richard Harnden wrote: > On 11/02/2024 12:38, bart wrote: >> On 11/02/2024 11:31, Richard Harnden wrote: >>> As a first stab, I'd use: >>> >>> gcc -std=c11 -pedantic -W -Wall -Wextra -Werror foo.c >>> >>> and try very hard to fix any/all warnings. >> >> >> That sounds like an incredibly slow and painful way to code. >> >> During development, you are adding, modifying, commenting, >> uncommenting and tearing down code all the time. >> >> C already requires you to dot all the Is and cross all the Ts because >> of its syntax and type needs. Why make the job even harder? > > Fixing things early /is/ easier. YMMobviouslyV. > > If it's something that needs to be fixed, or is even part of the final product. A lot of code may be replaced five minutes later. A program is gradually built and converges to its final form with lots of deviations along the way. Obviously my mileage /is/ different as I would find it stifling for it to conform to your standards at every single step of the way, even for code with an expected half-life measured in seconds. (As it happens, I write most substantial projects in a different language, and generate a C version, if needed, all at once using a transpiler. The development process in that other language is more informal, yet its compiler fails assignments between incompatible pointer types, and ignores unused labels. The sort of sensible behaviour I'd want in a C compiler by default.)
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-02-10 22:21 -0800 |
| Message-ID | <86jznb4j2r.fsf@linuxsc.com> |
| In reply to | #382278 |
bart <bc@freeuk.com> writes:
> On 10/02/2024 01:59, Tim Rentsch wrote:
>
>> bart <bc@freeuk.com> writes:
>>
>> [...]
>>
>>> This is something which has long been of fascination to me: how
>>> exactly do you get a C compiler to actually fail a program with a
>>> hard error when there is obviously something wrong, while not also
>>> failing on completely harmless matters.
>>
>> I think the answer is obvious: unless and until you find someone
>> who works on a C compiler and who has exactly the same sense that
>> you do of "when there is obviously something wrong" and of what
>> conditions fall under the heading of "completely harmless matters",
>> and also the same sense that you do of how a C compiler should
>> behave in those cases, you won't get exactly what you want unless
>> you do it yourself.
>
> Take this function:
>
> void F() {
> F();
> F(1);
> F(1, 2.0);
> F(1, 2.0, "3");
> F(1, 2.0, "3", F);
> }
>
> Even if /one/ of those calls is correct, the other four can't be
> possibly be correct as well.
>
> Is there anyone here who doesn't think there is something obviously wrong?
>
> How about this one:
>
> #include <stdio.h>
> int main(void) {
> int a;
> L1:
> printf("Hello, World!\n");
> }
>
> Ramp up the warnings and a compiler will tell you about unused 'a' and
> L1'. Use -Werror and the compilation will fail.
>
> Is there anyone here who thinks that running this program with those
> unused identifiers is not completely harmless?
In both cases the answer is, It depends.
There are scenarios where I would want the first example to compile
successfully and without any complaints. There are other scenarios
where I would want the second example to be given fatal errors during
compilation. Good compilers provide a range of options, knowing that
different circumstances call for different compilation outcomes.
Even if you want the same set of error and warning conditions in
every single compile that you do, other people don't. So you better
get used to the idea of setting the various options the way you want
them, or else write your own compiler and discover that no one else
will use it because it doesn't offer any way to select the particular
sets of choices they need for the various compilation scenarios that
are important to what they're doing.
[toc] | [prev] | [standalone]
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
Back to top | Article view | comp.lang.c
csiph-web