Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #167561 > unrolled thread

"Richard Stallman Announces C Reference"

Back to article view | Back to comp.lang.c

Contents

  "Richard Stallman Announces C Reference" Lynn McGuire <lynnmcguire5@gmail.com> - 2022-09-09 12:49 -0500
    Re: "Richard Stallman Announces C Reference" scott@slp53.sl.home (Scott Lurndal) - 2022-09-09 19:03 +0000
    Re: "Richard Stallman Announces C Reference" Thiago Adams <thiago.adams@gmail.com> - 2022-09-09 12:54 -0700
      Re: "Richard Stallman Announces C Reference" gazelle@shell.xmission.com (Kenny McCormack) - 2022-09-09 20:06 +0000
        Re: "Richard Stallman Announces C Reference" John Forkosh <forkosh@panix.com> - 2022-09-10 02:00 +0000
          Re: "Richard Stallman Announces C Reference" John Forkosh <forkosh@panix.com> - 2022-09-10 12:09 +0000
          Re: "Richard Stallman Announces C Reference" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-11 06:31 -0700
            Re: "Richard Stallman Announces C Reference" John Forkosh <forkosh@panix.com> - 2022-09-13 02:19 +0000
      Re: "Richard Stallman Announces C Reference" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-09 13:10 -0700
      Re: "Richard Stallman Announces C Reference" scott@slp53.sl.home (Scott Lurndal) - 2022-09-09 20:11 +0000
        Re: "Richard Stallman Announces C Reference" Thiago Adams <thiago.adams@gmail.com> - 2022-09-09 16:34 -0700
    Re: "Richard Stallman Announces C Reference" Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-10 18:16 +0200
      Re: "Richard Stallman Announces C Reference" scott@slp53.sl.home (Scott Lurndal) - 2022-09-10 17:04 +0000
        Re: "Richard Stallman Announces C Reference" Muttley@dastardlyhq.com - 2022-09-11 08:29 +0000
        Re: "Richard Stallman Announces C Reference" Manfred <noname@add.invalid> - 2022-09-24 16:24 +0200
          C++ is for real, C is just a toy (Was: "Richard Stallman Announces C Reference") gazelle@shell.xmission.com (Kenny McCormack) - 2022-09-24 15:54 +0000
            Re: C++ is for real, C is just a toy (Was: "Richard Stallman Announces C Reference") Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-24 18:07 +0200
      Re: "Richard Stallman Announces C Reference" Muttley@dastardlyhq.com - 2022-09-11 08:29 +0000
        Re: "Richard Stallman Announces C Reference" Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-11 11:16 +0200
          Re: "Richard Stallman Announces C Reference" Muttley@dastardlyhq.com - 2022-09-11 09:44 +0000
            Re: "Richard Stallman Announces C Reference" Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-11 13:42 +0200
              Re: "Richard Stallman Announces C Reference" Muttley@dastardlyhq.com - 2022-09-11 15:44 +0000
                Re: "Richard Stallman Announces C Reference" Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-11 17:55 +0200
                  Re: "Richard Stallman Announces C Reference" Muttley@dastardlyhq.com - 2022-09-11 16:17 +0000
                    Re: "Richard Stallman Announces C Reference" Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-11 18:22 +0200
                  Re: "Richard Stallman Announces C Reference" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-09-11 12:41 -0700
                    Re: "Richard Stallman Announces C Reference" Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-12 06:10 +0200
                      Re: "Richard Stallman Announces C Reference" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-09-12 00:27 -0700
                Re: "Richard Stallman Announces C Reference" Bo Persson <bo@bo-persson.se> - 2022-09-12 09:18 +0200
                  Re: "Richard Stallman Announces C Reference" Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-12 09:42 +0200
                  Re: "Richard Stallman Announces C Reference" Muttley@dastardlyhq.com - 2022-09-12 15:58 +0000
                    Re: "Richard Stallman Announces C Reference" Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-12 18:48 +0200
                Re: "Richard Stallman Announces C Reference" Juha Nieminen <nospam@thanks.invalid> - 2022-09-13 06:47 +0000
                  Re: "Richard Stallman Announces C Reference" Muttley@dastardlyhq.com - 2022-09-13 13:29 +0000
                    Re: "Richard Stallman Announces C Reference" Juha Nieminen <nospam@thanks.invalid> - 2022-09-14 05:56 +0000
                      Re: "Richard Stallman Announces C Reference" Muttley@dastardlyhq.com - 2022-09-14 09:37 +0000
          Re: "Richard Stallman Announces C Reference" scott@slp53.sl.home (Scott Lurndal) - 2022-09-11 16:26 +0000
            Re: "Richard Stallman Announces C Reference" Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-11 18:35 +0200
          Re: "Richard Stallman Announces C Reference" Opus <ifonly@youknew.org> - 2022-09-12 19:22 +0200
            Re: "Richard Stallman Announces C Reference" legalize+jeeves@mail.xmission.com (Richard) - 2022-09-22 19:24 +0000
    Re: "Richard Stallman Announces C Reference" Manu Raju <MR@invalid.invalid> - 2022-09-11 00:01 +0100
      Re: "Richard Stallman Announces C Reference" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-10 16:26 -0700
    Re: "Richard Stallman Announces C Reference" legalize+jeeves@mail.xmission.com (Richard) - 2022-09-22 19:21 +0000

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#167597

Am 11.09.2022 um 11:44 schrieb Muttley@dastardlyhq.com:

> The necessity is for a language that can have embedded assembler, is very
> efficient to compile and once compiled and is explicit. Because of this
> C++'s hidden conversions, exceptions and most of the STL can be ruled
> out which doesn't leave much left thats an advantage over C.

That all isn't a problem in the kernel if you know what you do.
Kernel-Programmers are very skilled and the should be able to
handle that, but it's not up to their mindset.
I wouldn't say that everything of the STL could be used inside
the kernel, but it would be possible to write adaptions, f.e.
to use special allocators for different types of allocations.
Exceptions wouldn't be a problem inside the kernel, although
they wouldn't make sense in any place.

[toc] | [prev] | [next] | [standalone]

#167606

On Sun, 11 Sep 2022 13:42:20 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Am 11.09.2022 um 11:44 schrieb Muttley@dastardlyhq.com:
>
>> The necessity is for a language that can have embedded assembler, is very
>> efficient to compile and once compiled and is explicit. Because of this
>> C++'s hidden conversions, exceptions and most of the STL can be ruled
>> out which doesn't leave much left thats an advantage over C.
>
>That all isn't a problem in the kernel if you know what you do.
>Kernel-Programmers are very skilled and the should be able to
>handle that, but it's not up to their mindset.

Its nothing to do with their mindset, its to do with knowing EXACTLY what the
code is going to do and/or where the program counter is going to go. There
is nothing to fall back on to tidy up any fuckups and no C++ runtime to hold
your hand.

>I wouldn't say that everything of the STL could be used inside
>the kernel, but it would be possible to write adaptions, f.e.
>to use special allocators for different types of allocations.

You could in theory do a lot of things. Whether the time and effort and extra
bloat would be worth it is another matter. Also the STL throws exceptions and
does hidden conversions.

>Exceptions wouldn't be a problem inside the kernel, although
>they wouldn't make sense in any place.

Oh yes they would. The kernel already has its own type of exceptions and has
to deal with low level interrupts. The last thing the code needs is C++
exceptions where something gets thrown and the program counter ends up god
knows where because someone forgot to do a catch 5 levels up.

[toc] | [prev] | [next] | [standalone]

#167607

Am 11.09.2022 um 17:44 schrieb Muttley@dastardlyhq.com:

>> That all isn't a problem in the kernel if you know what you do.
>> Kernel-Programmers are very skilled and the should be able to
>> handle that, but it's not up to their mindset.

> Its nothing to do with their mindset, its to do with knowing EXACTLY what the
> code is going to do and/or where the program counter is going to go. There
> is nothing to fall back on to tidy up any fuckups and no C++ runtime to hold
> your hand.

If you know C++ it's easy to understand what's happening behind the
scenes. Your problem is that you don't understand the language.

> You could in theory do a lot of things. Whether the time and effort and extra
> bloat would be worth it is another matter. Also the STL throws exceptions and
> does hidden conversions.

There's nothing boatish with STL.
STL does things you'd otherwise do manually.

> Oh yes they would. The kernel already has its own type of exceptions and
> has to deal with low level interrupts. ...

I don't have interrupts in mind when I talk about exceptions.
And in interrupts you won't allocate resources so it's not
necessary to throw excpetions within them.

> The last thing the code needs is C++ exceptions where something gets
> thrown and the program counter ends up god knows where because someone
> forgot to do a catch 5 levels up.

Exceptions need some documentation, but thats easier than manual
return code handling.

[toc] | [prev] | [next] | [standalone]

#167609

On Sun, 11 Sep 2022 17:55:22 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Am 11.09.2022 um 17:44 schrieb Muttley@dastardlyhq.com:
>
>>> That all isn't a problem in the kernel if you know what you do.
>>> Kernel-Programmers are very skilled and the should be able to
>>> handle that, but it's not up to their mindset.
>
>> Its nothing to do with their mindset, its to do with knowing EXACTLY what the
>
>> code is going to do and/or where the program counter is going to go. There
>> is nothing to fall back on to tidy up any fuckups and no C++ runtime to hold
>> your hand.
>
>If you know C++ it's easy to understand what's happening behind the
>scenes. Your problem is that you don't understand the language.

And you don't understand low level programming. But we knew that already.

[toc] | [prev] | [next] | [standalone]

#167610

Am 11.09.2022 um 18:17 schrieb Muttley@dastardlyhq.com:

> And you don't understand low level programming. But we knew that already.

I understand low level programming very good and with every
abstraction step I do I understand what's going on at the
lowest level behind what I do.

[toc] | [prev] | [next] | [standalone]

#167618

On 9/11/2022 8:55 AM, Bonita Montero wrote:
> Am 11.09.2022 um 17:44 schrieb Muttley@dastardlyhq.com:
> 
>>> That all isn't a problem in the kernel if you know what you do.
>>> Kernel-Programmers are very skilled and the should be able to
>>> handle that, but it's not up to their mindset.
> 
>> Its nothing to do with their mindset, its to do with knowing EXACTLY 
>> what the
>> code is going to do and/or where the program counter is going to go. 
>> There
>> is nothing to fall back on to tidy up any fuckups and no C++ runtime 
>> to hold
>> your hand.
> 
> If you know C++ it's easy to understand what's happening behind the
> scenes. Your problem is that you don't understand the language.
[...]

Perhaps I am misunderstanding you here, but, there are differences 
behind different STL implementations, no?

[toc] | [prev] | [next] | [standalone]

#167626

Am 11.09.2022 um 21:41 schrieb Chris M. Thomasson:
> On 9/11/2022 8:55 AM, Bonita Montero wrote:
>> Am 11.09.2022 um 17:44 schrieb Muttley@dastardlyhq.com:
>>
>>>> That all isn't a problem in the kernel if you know what you do.
>>>> Kernel-Programmers are very skilled and the should be able to
>>>> handle that, but it's not up to their mindset.
>>
>>> Its nothing to do with their mindset, its to do with knowing EXACTLY 
>>> what the
>>> code is going to do and/or where the program counter is going to go. 
>>> There
>>> is nothing to fall back on to tidy up any fuckups and no C++ runtime 
>>> to hold
>>> your hand.
>>
>> If you know C++ it's easy to understand what's happening behind the
>> scenes. Your problem is that you don't understand the language.
> [...]
> 
> Perhaps I am misunderstanding you here, but, there are differences 
> behind different STL implementations, no?

I think mostly not since the way they're impemented is obvious.

[toc] | [prev] | [next] | [standalone]

#167630

On 9/11/2022 9:10 PM, Bonita Montero wrote:
> Am 11.09.2022 um 21:41 schrieb Chris M. Thomasson:
>> On 9/11/2022 8:55 AM, Bonita Montero wrote:
>>> Am 11.09.2022 um 17:44 schrieb Muttley@dastardlyhq.com:
>>>
>>>>> That all isn't a problem in the kernel if you know what you do.
>>>>> Kernel-Programmers are very skilled and the should be able to
>>>>> handle that, but it's not up to their mindset.
>>>
>>>> Its nothing to do with their mindset, its to do with knowing EXACTLY 
>>>> what the
>>>> code is going to do and/or where the program counter is going to go. 
>>>> There
>>>> is nothing to fall back on to tidy up any fuckups and no C++ runtime 
>>>> to hold
>>>> your hand.
>>>
>>> If you know C++ it's easy to understand what's happening behind the
>>> scenes. Your problem is that you don't understand the language.
>> [...]
>>
>> Perhaps I am misunderstanding you here, but, there are differences 
>> behind different STL implementations, no?
> 
> I think mostly not since the way they're impemented is obvious.
> 
> 

Remember way back, iirc, msvc 6.0 used Dinkumware?

https://www.dinkumware.com/

A twisted nest of code that was! Good luck...

[toc] | [prev] | [next] | [standalone]

#167629

On 2022-09-11 at 17:44, Muttley@dastardlyhq.com wrote:
> On Sun, 11 Sep 2022 13:42:20 +0200
> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Am 11.09.2022 um 11:44 schrieb Muttley@dastardlyhq.com:
>>
>>> The necessity is for a language that can have embedded assembler, is very
>>> efficient to compile and once compiled and is explicit. Because of this
>>> C++'s hidden conversions, exceptions and most of the STL can be ruled
>>> out which doesn't leave much left thats an advantage over C.
>>
>> That all isn't a problem in the kernel if you know what you do.
>> Kernel-Programmers are very skilled and the should be able to
>> handle that, but it's not up to their mindset.
> 
> Its nothing to do with their mindset, its to do with knowing EXACTLY what the
> code is going to do and/or where the program counter is going to go. 

I have never understood how you can know EXACTLY what the code does in

int y = f(x);

but have no clue about what happens in

my_class f(x);

[toc] | [prev] | [next] | [standalone]

#167631

Am 12.09.2022 um 09:18 schrieb Bo Persson:
> On 2022-09-11 at 17:44, Muttley@dastardlyhq.com wrote:
>> On Sun, 11 Sep 2022 13:42:20 +0200
>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>> Am 11.09.2022 um 11:44 schrieb Muttley@dastardlyhq.com:
>>>
>>>> The necessity is for a language that can have embedded assembler, is 
>>>> very
>>>> efficient to compile and once compiled and is explicit. Because of this
>>>> C++'s hidden conversions, exceptions and most of the STL can be ruled
>>>> out which doesn't leave much left thats an advantage over C.
>>>
>>> That all isn't a problem in the kernel if you know what you do.
>>> Kernel-Programmers are very skilled and the should be able to
>>> handle that, but it's not up to their mindset.
>>
>> Its nothing to do with their mindset, its to do with knowing EXACTLY 
>> what the
>> code is going to do and/or where the program counter is going to go. 
> 
> I have never understood how you can know EXACTLY what the code does in
> 
> int y = f(x);
> 
> but have no clue about what happens in
> 
> my_class f(x);

That's a function that returns a my_class object.
This object is mostly moved from inside f( x ).
if f( x ) is inlined this move is optimized away.

[toc] | [prev] | [next] | [standalone]

#167645

On Mon, 12 Sep 2022 09:18:44 +0200
Bo Persson <bo@bo-persson.se> wrote:
>On 2022-09-11 at 17:44, Muttley@dastardlyhq.com wrote:
>> On Sun, 11 Sep 2022 13:42:20 +0200
>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>> Am 11.09.2022 um 11:44 schrieb Muttley@dastardlyhq.com:
>>>
>>>> The necessity is for a language that can have embedded assembler, is very
>>>> efficient to compile and once compiled and is explicit. Because of this
>>>> C++'s hidden conversions, exceptions and most of the STL can be ruled
>>>> out which doesn't leave much left thats an advantage over C.
>>>
>>> That all isn't a problem in the kernel if you know what you do.
>>> Kernel-Programmers are very skilled and the should be able to
>>> handle that, but it's not up to their mindset.
>> 
>> Its nothing to do with their mindset, its to do with knowing EXACTLY what the
>
>> code is going to do and/or where the program counter is going to go. 
>
>I have never understood how you can know EXACTLY what the code does in
>
>int y = f(x);
>
>but have no clue about what happens in
>
>my_class f(x);

And if that instance has virtual functions where will the VFT go and what
allocates it? Ditto any non primitive types which may cause an implcit cascade 
of allocations.

People like yourself and Bonita just don't seem to get the fact that there's no
safety net inside ring 0 code. You can't just handwave away stuff that in 
application code would be taken care of by the runtime.

[toc] | [prev] | [next] | [standalone]

#167649

Am 12.09.2022 um 17:58 schrieb Muttley@dastardlyhq.com:
> On Mon, 12 Sep 2022 09:18:44 +0200
> Bo Persson <bo@bo-persson.se> wrote:
>> On 2022-09-11 at 17:44, Muttley@dastardlyhq.com wrote:
>>> On Sun, 11 Sep 2022 13:42:20 +0200
>>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>> Am 11.09.2022 um 11:44 schrieb Muttley@dastardlyhq.com:
>>>>
>>>>> The necessity is for a language that can have embedded assembler, is very
>>>>> efficient to compile and once compiled and is explicit. Because of this
>>>>> C++'s hidden conversions, exceptions and most of the STL can be ruled
>>>>> out which doesn't leave much left thats an advantage over C.
>>>>
>>>> That all isn't a problem in the kernel if you know what you do.
>>>> Kernel-Programmers are very skilled and the should be able to
>>>> handle that, but it's not up to their mindset.
>>>
>>> Its nothing to do with their mindset, its to do with knowing EXACTLY what the
>>
>>> code is going to do and/or where the program counter is going to go.
>>
>> I have never understood how you can know EXACTLY what the code does in
>>
>> int y = f(x);
>>
>> but have no clue about what happens in
>>
>> my_class f(x);
> 
> And if that instance has virtual functions where will the VFT go and what
> allocates it? Ditto any non primitive types which may cause an implcit cascade
> of allocations.
> 
> People like yourself and Bonita just don't seem to get the fact that there's no
> safety net inside ring 0 code. You can't just handwave away stuff that in
> application code would be taken care of by the runtime.
> 

You're mentally like ring 0 - the whole day.

[toc] | [prev] | [next] | [standalone]

#167661

In comp.lang.c++ Muttley@dastardlyhq.com wrote:
> On Sun, 11 Sep 2022 13:42:20 +0200
> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>Am 11.09.2022 um 11:44 schrieb Muttley@dastardlyhq.com:
>>
>>> The necessity is for a language that can have embedded assembler, is very
>>> efficient to compile and once compiled and is explicit. Because of this
>>> C++'s hidden conversions, exceptions and most of the STL can be ruled
>>> out which doesn't leave much left thats an advantage over C.
>>
>>That all isn't a problem in the kernel if you know what you do.
>>Kernel-Programmers are very skilled and the should be able to
>>handle that, but it's not up to their mindset.
> 
> Its nothing to do with their mindset, its to do with knowing EXACTLY what the
> code is going to do and/or where the program counter is going to go. There
> is nothing to fall back on to tidy up any fuckups and no C++ runtime to hold
> your hand.

You seem to think that the Linux kernel has some kind of extraordinarily
strict requirement in terms of what the code is doing, at the lowest level,
so that it's always absolutely clear exactly what the CPU is doing at any
given moment, what the values of registers (especially the instruction
pointer) are, and so on.

You seem to be painting kernel code as something that it actually isn't.
There's nothing particularly special about kernel code. The vast majority
of it is just pretty normal C code with no special requirements. You
don't need to know "where the program counter is going to go". Why
would you? For what reason? If an interrupt happens, then registers are
stored as normal and then restored.

(The only peculiar limitation in kernel code is that you can't use the
standard C library for anything, because most of it cannot work at the
kernel level, especially at boot time before any partitions have been
mounted and thus no dynamically loadable libraries can be used. However,
this just limits your use of the standard library, for practical reasons
rather than "you need to always know where the program counter is going
to go". The kernel offers alternatives for most of the standard library
utilities that are useful in kernel code.)

[toc] | [prev] | [next] | [standalone]

#167668

On Tue, 13 Sep 2022 06:47:53 -0000 (UTC)
Juha Nieminen <nospam@thanks.invalid> wrote:
>(The only peculiar limitation in kernel code is that you can't use the
>standard C library for anything, because most of it cannot work at the
>kernel level, especially at boot time before any partitions have been
>mounted and thus no dynamically loadable libraries can be used. However,

Oh dear, and you were doing so well.

Heard of libc.a?

[toc] | [prev] | [next] | [standalone]

#167697

In comp.lang.c++ Muttley@dastardlyhq.com wrote:
> On Tue, 13 Sep 2022 06:47:53 -0000 (UTC)
> Juha Nieminen <nospam@thanks.invalid> wrote:
>>(The only peculiar limitation in kernel code is that you can't use the
>>standard C library for anything, because most of it cannot work at the
>>kernel level, especially at boot time before any partitions have been
>>mounted and thus no dynamically loadable libraries can be used. However,
> 
> Oh dear, and you were doing so well.
> 
> Heard of libc.a?

I don't understand what you are trying to say.

You cannot use the standard C library in kernel code. It's a hard rule.
The kernel sources provide their own alternatives for most standard
library utilities that are useful in kernel code.

If you didn't know that and you don't believe me, just check it out.
And while you are at it, check out *why* you can't use it.

[toc] | [prev] | [next] | [standalone]

#167702

On Wed, 14 Sep 2022 05:56:20 -0000 (UTC)
Juha Nieminen <nospam@thanks.invalid> wrote:
>In comp.lang.c++ Muttley@dastardlyhq.com wrote:
>> On Tue, 13 Sep 2022 06:47:53 -0000 (UTC)
>> Juha Nieminen <nospam@thanks.invalid> wrote:
>>>(The only peculiar limitation in kernel code is that you can't use the
>>>standard C library for anything, because most of it cannot work at the
>>>kernel level, especially at boot time before any partitions have been
>>>mounted and thus no dynamically loadable libraries can be used. However,
>> 
>> Oh dear, and you were doing so well.
>> 
>> Heard of libc.a?
>
>I don't understand what you are trying to say.
>
>You cannot use the standard C library in kernel code. It's a hard rule.
>The kernel sources provide their own alternatives for most standard
>library utilities that are useful in kernel code.
>
>If you didn't know that and you don't believe me, just check it out.
>And while you are at it, check out *why* you can't use it.

The reason is nothing to with with dynamically loadable libraries as you
stated. That was my point. 

[toc] | [prev] | [next] | [standalone]

#167612

Bonita Montero <Bonita.Montero@gmail.com> writes:
>Am 11.09.2022 um 10:29 schrieb Muttley@dastardlyhq.com:
>> On Sat, 10 Sep 2022 18:16:45 +0200
>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>> Am 09.09.2022 um 19:49 schrieb Lynn McGuire:
>>>> "Richard Stallman Announces C Reference"
>>>>
>>>>
>>> https://www.i-programmer.info/news/184-cc/15705-richard-stallman-announces-c-re
>>> ference.html
>>>>
>>>> "Richard Stallman (RMS) is a controversial figure - you either like or
>>>> dislike him - but you have to assume he knows his C. So an announcement
>>>> that he has a book on the subject is interesting."
>>>>
>>>> "As you might guess, being the founder of the Free Software Foundation,
>>>> Stallman's book is free to download, but at this stage you will have to
>>>> do some work if you want to read it and it seems to be still in beta.
>>>> The text contains requests for comments."
>>>>
>>>> I did not know that RS wrote the first gcc compiler.
>>>>
>>>> Lynn
>>>
>>> C is a good language to learn programming
>>> but actually not to solve real tasks.
>> 
>> Real tasks such as most OS kernels and all the GNU command line utilities?
>
>That's a matter of the writer's mindset and tradition and
>not of necessities.

But they "solve real tasks", which you claimed wasn't the case. Admit
you were wrong, just this once.

[toc] | [prev] | [next] | [standalone]

#167615

Am 11.09.2022 um 18:26 schrieb Scott Lurndal:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
>> Am 11.09.2022 um 10:29 schrieb Muttley@dastardlyhq.com:
>>> On Sat, 10 Sep 2022 18:16:45 +0200
>>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>> Am 09.09.2022 um 19:49 schrieb Lynn McGuire:
>>>>> "Richard Stallman Announces C Reference"
>>>>>
>>>>>
>>>> https://www.i-programmer.info/news/184-cc/15705-richard-stallman-announces-c-re
>>>> ference.html
>>>>>
>>>>> "Richard Stallman (RMS) is a controversial figure - you either like or
>>>>> dislike him - but you have to assume he knows his C. So an announcement
>>>>> that he has a book on the subject is interesting."
>>>>>
>>>>> "As you might guess, being the founder of the Free Software Foundation,
>>>>> Stallman's book is free to download, but at this stage you will have to
>>>>> do some work if you want to read it and it seems to be still in beta.
>>>>> The text contains requests for comments."
>>>>>
>>>>> I did not know that RS wrote the first gcc compiler.
>>>>>
>>>>> Lynn
>>>>
>>>> C is a good language to learn programming
>>>> but actually not to solve real tasks.
>>>
>>> Real tasks such as most OS kernels and all the GNU command line utilities?
>>
>> That's a matter of the writer's mindset and tradition and
>> not of necessities.
> 
> But they "solve real tasks", which you claimed wasn't the case.
> Admit you were wrong, just this once.

Yes they do, but with much more work than a proper language
would make.

[toc] | [prev] | [next] | [standalone]

#167650

Le 11/09/2022 à 11:16, Bonita Montero a écrit :
> Am 11.09.2022 um 10:29 schrieb Muttley@dastardlyhq.com:
>> On Sat, 10 Sep 2022 18:16:45 +0200
>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>> Am 09.09.2022 um 19:49 schrieb Lynn McGuire:
>>>> "Richard Stallman Announces C Reference"
>>>>
>>>>
>>> https://www.i-programmer.info/news/184-cc/15705-richard-stallman-announces-c-re
>>> ference.html
>>>>
>>>> "Richard Stallman (RMS) is a controversial figure - you either like or
>>>> dislike him - but you have to assume he knows his C. So an announcement
>>>> that he has a book on the subject is interesting."
>>>>
>>>> "As you might guess, being the founder of the Free Software Foundation,
>>>> Stallman's book is free to download, but at this stage you will have to
>>>> do some work if you want to read it and it seems to be still in beta.
>>>> The text contains requests for comments."
>>>>
>>>> I did not know that RS wrote the first gcc compiler.
>>>>
>>>> Lynn
>>>
>>> C is a good language to learn programming
>>> but actually not to solve real tasks.
>>
>> Real tasks such as most OS kernels and all the GNU command line 
>> utilities?
> 
> That's a matter of the writer's mindset and tradition and
> not of necessities.

What's exactly the point of keeping trolling the comp.lang.c group while 
carefully cross-posting to the c++ one just in case we didn't get it 
(and probably to show your c++ peers that you're a faithful promoter)?

What do you get from it and why is it that people keep replying? That's 
polluting a good half of the new posts. Good lord.

[toc] | [prev] | [next] | [standalone]

#167802

[Please do not mail me a copy of your followup]

Opus <ifonly@youknew.org> spake the secret code
<tfnpti$cb6$1@gioia.aioe.org> thusly:

>What's exactly the point of keeping trolling [...]

Why, to improve your KILL file, naturally.
-- 
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
            The Terminals Wiki <http://terminals-wiki.org>
     The Computer Graphics Museum <http://computergraphicsmuseum.org>
  Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web