"Richard Stallman Announces C Reference"

[Lynn McGuire]

"Richard Stallman Announces C Reference"

https://www.i-programmer.info/news/184-cc/15705-richard-stallman-announces-c-reference.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

[Scott Lurndal]

Lynn McGuire <lynnmc...@gmail.com> writes:
>"Richard Stallman Announces C Reference"
>
>https://www.i-programmer.info/news/184-cc/15705-richard-stallman-announces-c-reference.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."

You know what they say about assumption. He hasn't had much to
do with the compiler for a couple of decades now.

[Bonita Montero]

C is a good language to learn programming
but actually not to solve real tasks.

[Scott Lurndal]

I think you have that backwards. Really.

[Michael S]

I don't know about Linux, but on Windows in order to read his book, which, supposedly,
weigh 1 or 5 MB, one needs to download ~200 MB worth of software that expands to
~900 MB of disk space. And that's would be sufficient only if you already have msys2,
gcc, python, make and binutils installed. Which is true in case of myself, but but wrong
for 99% of Windows users. So, for those 99% there is a need to install another 2 or 5 GB.

I wonder, if RMS is doing it intentionally or out of ignorance.

[Keith Thompson]

Michael S <already...@yahoo.com> writes:
> On Friday, September 9, 2022 at 8:49:42 PM UTC+3, Lynn McGuire wrote:
>> "Richard Stallman Announces C Reference"
>>
>> https://www.i-programmer.info/news/184-cc/15705-richard-stallman-announces-c-reference.html

[...]

>
> I don't know about Linux, but on Windows in order to read his book,
> which, supposedly, weigh 1 or 5 MB, one needs to download ~200 MB
> worth of software that expands to ~900 MB of disk space. And that's
> would be sufficient only if you already have msys2, gcc, python, make
> and binutils installed. Which is true in case of myself, but but wrong
> for 99% of Windows users. So, for those 99% there is a need to install
> another 2 or 5 GB.
>
> I wonder, if RMS is doing it intentionally or out of ignorance.

I wouldn't quite say it's deliberate, but RMS fairly clearly does not
care about Windows or other non-free software. He probably wouldn't go
out of his way to make things difficult on Windows, but I'm reasonably
sure he wouldn't expend any effort to make things easier. He wants
everyone to stop using Windows.

The pdf version is easy to generate *if* you already have the right
infrastructure, and I presume it will become available, which means
Windows users can use it directly.

(Please do not turn this into a debate about the merits of his
opinions.)

--
Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

[Manu Raju]

How is this different from this file?

<https://gcc.gnu.org/onlinedocs/gcc-12.2.0/cpp.pdf>

[Keith Thompson]

That's a manual for the GNU C preprocessor.

This new document is about the C language (with a strong emphasis on the
gcc variant). It's intended to incorporate the preprocessor manual.

[Alf P. Steinbach]

I typed `bash` in Windows Cmd, to enter Ubuntu in Windows Subsystem for
Linux, and followed the given recipe:

sudo apt update
sudo apt install texlive-latex-extra
sudo apt install ghostscript
sudo apt install texinfo
git clone https://git.savannah.gnu.org/git/c-intro-and-ref.git
cd c-intro-and-ref
makeinfo --html -v c.texi -o c.html --no-split


I just changed "html" to "pdf".

For some reason it wouldn't accept these commands in one single paste. I
had to paste one command at a time. And in typical *nix land fashion
each produced an avalanche of installation progress messages, gah.

But it worked. :) The generated PDF has a standard bookmarks contents
listing, that's nice.

---

Just by skimming through the pages I learned that the g++ restriction to
Unicode escapes in identifiers, not the Unicode characters themselves,
is actually a C restriction, one that I was not aware of.

So, g++ implements the C rules, but not the C++ rules.

Interesting.


- Alf

[Mut...@dastardlyhq.com]

Real tasks such as most OS kernels and all the GNU command line utilities?

[Mut...@dastardlyhq.com]

Story of his/her/its life.

[Bonita Montero]

That's a matter of the writer's mindset and tradition and
not of necessities.

[Mut...@dastardlyhq.com]

On Sun, 11 Sep 2022 11:16:14 +0200

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.

[Bonita Montero]

Am 11.09.2022 um 11:44 schrieb Mut...@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.

[David Brown]

Lots of people who write technical books do so using TeX (or something
based on TeX - LaTeX, texinfo, etc.). There is nothing that compares to
TeX (and its friends), in the right hands, for the quality of the
output. And for people who are used to it, it is vastly more efficient
in use than word processors or other gui tools.

So, do you think he should be using significantly inferior tools just
because people using an inferior OS (in his eyes, at least) probably
don't have these tools already installed? Of course not.

This book is a work in progress, as I understand it. When it is ready,
I'm sure you'll be able to view it as a pdf or html on whatever system
you like. In the meantime, if you want to see its current state, you
have to have the appropriate software.

[Michael S]

No, I think that he should periodically check in generated .html or .pdf
or both into source control. Once per month sounds like good enough.
And at the same time to push it to one of the popular repositories with
no0b-friendly front end. Preferably, github, but if his ideological pureness
does not allow that then one of several alternatives.
Of course, if somebody wants to be totally user-friendly then he would
supply one of e-book formats as well, e.g. ideologically acceptable epub.
But I realize that in this particular case it is too much to ask.

As to word processors, I am in a full agreement with everybody who thinks
that word processor format is not any better for distribution of the book
than internal format of RMS's tools.
I would be equally unhappy with the need to install MS Office or Libre
Office as I am with the need to install texlive-latex-extra.

>
> This book is a work in progress, as I understand it. When it is ready,
> I'm sure you'll be able to view it as a pdf or html on whatever system
> you like.

See, *I* already can see it as pdf or html on whatever system I like.
But I care (or pretend to care :-) about less tech-savvy souls.
And about wasting Internet bandwidth and disk space.

> In the meantime, if you want to see its current state, you
> have to have the appropriate software.

BTW, I didn't read it and there is approximately zero chance that I's ever
read it entirely, but I took a look at some topics and found it (surprise!)
rather reasonable in views and competently written.

[Mut...@dastardlyhq.com]

On Sun, 11 Sep 2022 13:42:20 +0200
Bonita Montero <Bonita....@gmail.com> wrote:
>Am 11.09.2022 um 11:44 schrieb Mut...@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.

[Bonita Montero]

Am 11.09.2022 um 17:44 schrieb Mut...@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.

[Mut...@dastardlyhq.com]

On Sun, 11 Sep 2022 17:55:22 +0200
Bonita Montero <Bonita....@gmail.com> wrote:
>Am 11.09.2022 um 17:44 schrieb Mut...@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.

[Bonita Montero]

Am 11.09.2022 um 18:17 schrieb Mut...@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.

[Scott Lurndal]

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

[Bonita Montero]

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

[Michael S]

Back in 2008 I found boost::intrusive project very promising.
It promised many of advantages as STL containers without any exceptions
and memory allocation outside of user's control.
Didn't follow it since then.
Would guess, it somehow didn't deliver otherwise by now it would be
part of STL.

[Bonita Montero]

Am 11.09.2022 um 18:51 schrieb Michael S:

> Back in 2008 I found boost::intrusive project very promising.
> It promised many of advantages as STL containers without any exceptions
> and memory allocation outside of user's control.
> Didn't follow it since then.
> Would guess, it somehow didn't deliver otherwise by now it would be
> part of STL.

I don't know why someone should drop exceptions. Error handling
is sinewy anyway, but exceptions are the most comfortable way to
have error-handling.

[Chris M. Thomasson]

On 9/11/2022 8:55 AM, Bonita Montero wrote:
> Am 11.09.2022 um 17:44 schrieb Mut...@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?

[Keith Thompson]

"Alf P. Steinbach" <alf.p.s...@gmail.com> writes:
[...]

> I typed `bash` in Windows Cmd, to enter Ubuntu in Windows Subsystem
> for Linux, and followed the given recipe:
>
> sudo apt update
> sudo apt install texlive-latex-extra
> sudo apt install ghostscript
> sudo apt install texinfo
> git clone https://git.savannah.gnu.org/git/c-intro-and-ref.git
> cd c-intro-and-ref
> makeinfo --html -v c.texi -o c.html --no-split
>
>
> I just changed "html" to "pdf".

[...]

Thanks for that.

I've found that the provided Makefile doesn't work very well. One minor
point: `make` creates files c, c-1, c-2, and c-3 (no ".info" suffix);
they're usable with the info command: `info ./c`, but it would be more
consistent to name the files c.info, c.info-1, et al. And `make clean`
doesn't delete c-3.

Based on your example above, here's what I use to generate info, pdf,
and html documents, once I have a clone of the repo and all required
tools installed:

makeinfo --pdf -v c.texi -o c-intro-and-ref.pdf --no-split
makeinfo --html -v c.texi -o c-intro-and-ref.html --no-split
makeinfo --info -v c.texi -o c-intro-and-ref.info --no-split

[Bonita Montero]

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

[Juha Nieminen]

Michael S <already...@yahoo.com> wrote:
> I don't know about Linux, but on Windows in order to read his book, which, supposedly,
> weigh 1 or 5 MB, one needs to download ~200 MB worth of software that expands to
> ~900 MB of disk space. And that's would be sufficient only if you already have msys2,
> gcc, python, make and binutils installed. Which is true in case of myself, but but wrong
> for 99% of Windows users. So, for those 99% there is a need to install another 2 or 5 GB.
>
> I wonder, if RMS is doing it intentionally or out of ignorance.

You can read the .texi file directly. It's not like it's some inscrutable highly
obfuscated binary format. It's actually significantly more legible than eg. XML.

[Bo Persson]

On 2022-09-11 at 17:44, Mut...@dastardlyhq.com wrote:
> On Sun, 11 Sep 2022 13:42:20 +0200
> Bonita Montero <Bonita....@gmail.com> wrote:
>> Am 11.09.2022 um 11:44 schrieb Mut...@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);

[Chris M. Thomasson]

Remember way back, iirc, msvc 6.0 used Dinkumware?

https://www.dinkumware.com/

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

[Bonita Montero]

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.

[Bo Persson]

It's a function only if x is a type. But x is a value, like in the int
case, so it is a constructor call.

> This object is mostly moved from inside f( x ).
> if f( x ) is inlined this move is optimized away.

And still, the C guys cannot see what happens here. So "improve" this as

struct my_class f;
init(&f, x);

And now it is suddenly obvious EXACTLY what happens? :-)

[Bonita Montero]

The C++-"guys" can !

[Mut...@dastardlyhq.com]

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.

[Bonita Montero]

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

[Opus]

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.

[Bo Persson]

On 2022-09-12 at 17:58, Mut...@dastardlyhq.com wrote:
> On Mon, 12 Sep 2022 09:18:44 +0200
> Bo Persson <b...@bo-persson.se> wrote:
>> On 2022-09-11 at 17:44, Mut...@dastardlyhq.com wrote:
>>> On Sun, 11 Sep 2022 13:42:20 +0200
>>> Bonita Montero <Bonita....@gmail.com> wrote:
>>>> Am 11.09.2022 um 11:44 schrieb Mut...@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.

Just don't see how we know that int y = f(x); doesn't call other
functions that allocate structs on the heap? Structs that contain
function pointers that are then called, cause an implicit 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 can look at the class declaration to see what the constructor does -
and that there are no virtual functions present. Just like you have to
verify what the C function does.

[Juha Nieminen]

In comp.lang.c++ Mut...@dastardlyhq.com wrote:
> On Sun, 11 Sep 2022 13:42:20 +0200
> Bonita Montero <Bonita....@gmail.com> wrote:
>>Am 11.09.2022 um 11:44 schrieb Mut...@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.)

[Mut...@dastardlyhq.com]

On Mon, 12 Sep 2022 20:32:21 +0200
Bo Persson <b...@bo-persson.se> wrote:
>On 2022-09-12 at 17:58, Mut...@dastardlyhq.com wrote:
>>> 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.
>
>Just don't see how we know that int y = f(x); doesn't call other
>functions that allocate structs on the heap? Structs that contain

It may well do, but you can at least look at them to see how and kernel authors
are extremely careful about how they allocate dynamic memory. Meanwhile
who knows if std::string s = "hello" will allocate on the heap or if it'll
use its small reerved amount of stack.

[Mut...@dastardlyhq.com]

On Tue, 13 Sep 2022 06:47:53 -0000 (UTC)
Juha Nieminen <nos...@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?

[Andreas Kempe]

In my view, this is not a language problem as much as a standard
library implementation problem. As have been brought up earlier, you
don't use the normal user space libc in the kernel for C code, but
have parts of the standard library implemented in a way to make it fit
the kernel.

To seriously bring C++ into the kernel world, one would have to do the
same. That is, pick functions from the standard library that make
sense in the kernel and implement them to work there. One such thing
could of course be an std::string without hidden heap allocations.

I, and doubtlessly many others, have long toyed with the idea that
kernel programming, Linux or *BSD is what I'm familiar with, could be
made simpler with a language that supports object oriented programming
instead of using C structs with function pointers. The possibility of
doing RAII would also be nice. Whether that language should be C++ is
another question and I don't have a good answer.

[Juha Nieminen]

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.

[Juha Nieminen]

Andreas Kempe <ke...@lysator.liu.se> wrote:
> I, and doubtlessly many others, have long toyed with the idea that
> kernel programming, Linux or *BSD is what I'm familiar with, could be
> made simpler with a language that supports object oriented programming
> instead of using C structs with function pointers. The possibility of
> doing RAII would also be nice. Whether that language should be C++ is
> another question and I don't have a good answer.

One of the stated reasons why the Linux kernel sticks with C is that it's
the kind of "lingua franca" of programming languages, when it comes
to low-level programming in general and Linux kernel development in
particular. Existing developers don't need to learn a new programming
language in order to eg. do code reviews of new submissions, or interact
with other parts of the code in their code.

If a new language were to be introduced into kernel code, like C++
(or, heaven forbid, Rust), that would mean that a huge amount of devs
would either need to learn the new language or just don't participate
(in code reviews, further development, etc), which would ostensibly
mean a significant drop in the number of expert developers. The kernel
is complex enough as it is; it would not benefit from half the
developers dropping off (and perhaps creating their own fork and
going there).

I'm not completely unsympathetic to that reasoning.

But yeah, some of the most complicated kernel drivers could perhaps
benefit from RAII and templates, if they were available.

[David Brown]

When working on an OS kernel, there are lots of things in the C standard
library that you avoid, and there is no difference in regard to C++. It
has a lot in common with embedded development, and that is often done in
C++. With the software I write, on microcontrollers, I am quite happy
to use C++, but I am careful about the features I use. Exceptions are
disabled, virtual inheritance is out (virtual functions are used with
caution), and there is rarely a good enough reason for anything
involving dynamic memory in my code.

For a large OS kernel, the precise choices of which features in the
language and library to use are a bit different from mine, but the same
principles apply. And you often end up writing classes and functions
that are somewhat similar to the standard library solutions, but which
are more suited to your particular needs. Lots of OS kernels are
already written in C++ - just not ones as visible as Linux or *BSD.

There are also existing template libraries that could be useful. A
particularly well-known one is EASTL, started by Electronic Arts as a
version of the STL (back when the containers part of the C++ standard
library was called the STL) that was better suited to high-performance
gaming code. I don't know if it is an ideal fit for a big OS kernel,
but it would likely be better than the standard library.

<https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html>
<https://github.com/electronicarts/EASTL>

[Mut...@dastardlyhq.com]

On Wed, 14 Sep 2022 05:56:20 -0000 (UTC)

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

[Andreas Kempe]

What size are we talking about? In a professional setting, I've only
worked with embedded systems large enough to run Linux. On those
systems we used C++ as the primary language, with Python being used
for some things as well. Due to using a full blown Linux system we
didn't really have any restrictions regarding what language features
to use so that was never a problem. When working on the kernel, we of
course used C.

I'm curious because I've occasionally searched around for C++ standard
implementations aimed at kernel programming or bare metal programming
without really finding much. For C, newlib is the one I have
personally used to write bare metal stuff and it worked well.

> For a large OS kernel, the precise choices of which features in the
> language and library to use are a bit different from mine, but the same
> principles apply. And you often end up writing classes and functions
> that are somewhat similar to the standard library solutions, but which
> are more suited to your particular needs. Lots of OS kernels are
> already written in C++ - just not ones as visible as Linux or *BSD.
>
> There are also existing template libraries that could be useful. A
> particularly well-known one is EASTL, started by Electronic Arts as a
> version of the STL (back when the containers part of the C++ standard
> library was called the STL) that was better suited to high-performance
> gaming code. I don't know if it is an ideal fit for a big OS kernel,
> but it would likely be better than the standard library.
>
><https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html>
><https://github.com/electronicarts/EASTL>
>

Interesting. I haven't really worked with high performance
applications like games in C++, but from what I've heard and read the
standard library quite often isn't enough for various reasons. I did
not know that EA had made their stuff open source and it frankly
surprises me, in a good way.

[Andreas Kempe]

This might be part of the reasoning, but I think the main reason is
that Linus is biased against C++ on the grounds of simply not liking
the language.

Here's a quote I managed to find again from when they were discussing
Rust support in the kernel:
>Asked about a suggestion by a commenter on the Linux Weekly News
>website, who said, during a discussion on the Google post, "The
>solution here is simple: just use C++ instead of Rust", Torvalds
>could not restrain himself from chortling. "LOL," was his response.
>"C++ solves _none_ of the C issues, and only makes things worse. It
>really is a crap language.
>
>"For people who don't like C, go to a language that actually offers
>you something worthwhile. Like languages with memory safety and
>[which] can avoid some of the dangers of C, or languages that have
>internal GC [garbage collection] support and make memory management
>easier. C++ solves all the wrong problems, and anybody who says
>'rewrite the kernel in C++' is too ignorant to even know that."

Source: https://developers.slashdot.org/story/21/04/17/009241/linus-torvalds-says-rust-closer-for-linux-kernel-development-calls-c-a-crap-language

> But yeah, some of the most complicated kernel drivers could perhaps
> benefit from RAII and templates, if they were available.

From my personal experince, it doesn't even have to be complex
drivers. The first pattern I would be happy to throw out is all the
goto cleanup;, goto unlock;, goto exit; etc you have to sprinkle
throughout the code as soon as you need to allocate or lock something.

[Juha Nieminen]

David Brown <david...@hesbynett.no> wrote:
> There are also existing template libraries that could be useful. A
> particularly well-known one is EASTL, started by Electronic Arts as a
> version of the STL (back when the containers part of the C++ standard
> library was called the STL) that was better suited to high-performance
> gaming code. I don't know if it is an ideal fit for a big OS kernel,
> but it would likely be better than the standard library.

Would probably not be usable without modifications because in (Linux)
kernel code you can't use 'malloc()' (and, I assume, consequently 'new').
The kernel provides its own dynamic memory allocation functions, so
any such dynamic library would need to be changed to use those.

[Juha Nieminen]

Andreas Kempe <ke...@lysator.liu.se> wrote:
> This might be part of the reasoning, but I think the main reason is
> that Linus is biased against C++ on the grounds of simply not liking
> the language.
>
> Here's a quote I managed to find again from when they were discussing
> Rust support in the kernel:

I still find it astonishing how much unprofessionalism there is in the
Linux development scene, even at the highest levels.

Just read the cringe language used in the *official* Linux kernel coding
style guideline page:
https://www.kernel.org/doc/html/v4.10/process/coding-style.html

(I'm not talking about the coding style itself, but the explanatory text.)

This kind of unprofessional language and attitude would have been
understandable in the 1990's, when Linux was just a really small hobby
project used by only a handful of people.

It's significantly less understandable today, when Linux is one of the most
if not the most used operating system in the world, used in and by extremely
large institutions and international corporations, and people who contribute
to its kernel code include giant tech megacorporations.

Just imagine doing business with a giant corporation, and using language
like that. It's astonishingly unprofessional and cringe.

[David Brown]

Smaller than that - usually a /lot/ smaller. I tend to think of
"embedded Linux systems" as primarily /Linux/ systems, rather than
primarily /embedded/ systems. Some people prefer "resource constrained
embedded systems" as an alternative name.

Basically, I am considering systems where you have a single statically
linked program. (You might have sometimes have an extra boot program,
or updater, or test program - but the normal mode of operation is one
program.)

> On those
> systems we used C++ as the primary language, with Python being used
> for some things as well. Due to using a full blown Linux system we
> didn't really have any restrictions regarding what language features
> to use so that was never a problem. When working on the kernel, we of
> course used C.

Sure. On embedded Linux systems, I too use Python - or whatever else
suits the task at hand.

>
> I'm curious because I've occasionally searched around for C++ standard
> implementations aimed at kernel programming or bare metal programming
> without really finding much. For C, newlib is the one I have
> personally used to write bare metal stuff and it worked well.
>

Newlib is the most common choice, as well as its variant newlib-nano
which is smaller (but more limited). I don't know of any good C++
standard library implementations targetting such systems - the
aforementioned EASTL is the nearest. Generally, I think, people make
their own classes as needed. So if you really need a dynamically sized
array (and usually you don't - a fixed size can be better in many ways,
and std::array is overhead-free), you just make one. It's not hard when
it is for a particular purpose. The effort in making the standard
library classes is having them robust in the face of users wanting
vectors of rvalue references to pointers to member functions, and
whatever else pesky users try to do. For use in a fixed program, you
can make them a /lot/ simpler and fine-tune them to your needs. It's a
bit more like C programming in that respect - you might have to invent
your own wheels, but you can make them exactly the shape you want.

>> For a large OS kernel, the precise choices of which features in the
>> language and library to use are a bit different from mine, but the same
>> principles apply. And you often end up writing classes and functions
>> that are somewhat similar to the standard library solutions, but which
>> are more suited to your particular needs. Lots of OS kernels are
>> already written in C++ - just not ones as visible as Linux or *BSD.
>>
>> There are also existing template libraries that could be useful. A
>> particularly well-known one is EASTL, started by Electronic Arts as a
>> version of the STL (back when the containers part of the C++ standard
>> library was called the STL) that was better suited to high-performance
>> gaming code. I don't know if it is an ideal fit for a big OS kernel,
>> but it would likely be better than the standard library.
>>
>> <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html>
>> <https://github.com/electronicarts/EASTL>
>>
>
> Interesting. I haven't really worked with high performance
> applications like games in C++, but from what I've heard and read the
> standard library quite often isn't enough for various reasons. I did
> not know that EA had made their stuff open source and it frankly
> surprises me, in a good way.

General container classes are much less used in high performance coding
now than they used to be. Your key focus in programming such
applications is cache usage - almost everything else (except getting the
graphics card to do the work instead of the processor) is secondary.

[David Brown]

I believe the EASTL is flexible enough to support any allocator you
want, though it has a different concept of allocator than the C++
standard library. And you can always override global "new".

But no, I am not suggesting that it would be an off-the-shelve solution
- merely that it is possible to have much of the convenience of C++
containers and other library features while avoiding some of the bits
you don't want in an OS kernel.

[Chris Vine]

On Wed, 14 Sep 2022 06:04:48 -0000 (UTC)
Juha Nieminen <nos...@thanks.invalid> wrote:
[snip]

> If a new language were to be introduced into kernel code, like C++
> (or, heaven forbid, Rust), that would mean that a huge amount of devs
> would either need to learn the new language or just don't participate
> (in code reviews, further development, etc), which would ostensibly
> mean a significant drop in the number of expert developers. The kernel
> is complex enough as it is; it would not benefit from half the
> developers dropping off (and perhaps creating their own fork and
> going there).

Rust is entering the linux kernel on an experimental basis, after
receiving approval from Torvalds. If support hasn't yet been merged
into mainline (I am not sure if it has or it hasn't) it is about to be.
Make of it what you will. Presumably much of the Rust standard library
isn't available.

[Juha Nieminen]

Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote:
>> If a new language were to be introduced into kernel code, like C++
>> (or, heaven forbid, Rust), that would mean that a huge amount of devs
>> would either need to learn the new language or just don't participate
>> (in code reviews, further development, etc), which would ostensibly
>> mean a significant drop in the number of expert developers. The kernel
>> is complex enough as it is; it would not benefit from half the
>> developers dropping off (and perhaps creating their own fork and
>> going there).
>
> Rust is entering the linux kernel on an experimental basis, after
> receiving approval from Torvalds. If support hasn't yet been merged
> into mainline (I am not sure if it has or it hasn't) it is about to be.
> Make of it what you will. Presumably much of the Rust standard library
> isn't available.

Let's hope that doesn't start a downspiral which starts by alienating
half of the current kernel developers.

Sometimes I think that Torvalds should relinquish control of his own
kernel, for its own good.

[Chris Vine]

I don't think Torvalds was the originator of this: instead he has agreed
to see if it works out. Rust seems to have received sufficiently
widespread approbation within the kernel community as I understand it
and I don't think there is (at least at present) any requirement to use
or even know the language unless you are hacking on the particular
modules that use it.

I should have thought the experiment was worth the effort. Memory
errors are still a significant source of bugs and vulnerabilities, and
the promise that, by virtue of Rust's linear/affine type system, a
component that compiles is guaranteed to be memory correct as long as
the unsafe subset of Rust hasn't been used is quite a strong statement.

[Michael S]

On Wednesday, September 14, 2022 at 3:21:17 PM UTC+3, Juha Nieminen wrote:
> Andreas Kempe <ke...@lysator.liu.se> wrote:
> > This might be part of the reasoning, but I think the main reason is
> > that Linus is biased against C++ on the grounds of simply not liking
> > the language.
> >
> > Here's a quote I managed to find again from when they were discussing
> > Rust support in the kernel:
> I still find it astonishing how much unprofessionalism there is in the
> Linux development scene, even at the highest levels.
>
> Just read the cringe language used in the *official* Linux kernel coding
> style guideline page:
> https://www.kernel.org/doc/html/v4.10/process/coding-style.html
>
> (I'm not talking about the coding style itself, but the explanatory text.)
>

I like the language of this text.
Style itself - less so; agree or accept with 80%, but not with another 20%.
It seems, what you consider "professional language" I'd consider boring
and bureaucratic. Or, may be, not. In order to know for sure you have to
give me an example of what you consider well-written style guide.

Of course, there is another problem: anarchistic part of me dislikes
the whole idea of style guides so when style guide is written in mundane
style it just adds insult to the injury.

On the other hand "mundane" style is not the worst in my book, what drives
me more crazy is "wake" style. Fortunately, "wake" is more likely to be
encountered in "codes of conduct" and less likely in "style guides".
And since in my book "codes of conduct" are sort of humorous prose
anyway, even when athors have different intentions, their language
is inherently less damaging to my blood pressure.

[Juha Nieminen]

Michael S <already...@yahoo.com> wrote:
>> Just read the cringe language used in the *official* Linux kernel coding
>> style guideline page:
>> https://www.kernel.org/doc/html/v4.10/process/coding-style.html
>>
>

> I like the language of this text.
> Style itself - less so; agree or accept with 80%, but not with another 20%.
> It seems, what you consider "professional language" I'd consider boring
> and bureaucratic. Or, may be, not. In order to know for sure you have to
> give me an example of what you consider well-written style guide.

An official documentation intended for use by companies and individual
people from all around the world, both hobbyists and professionals,
from a wide variety of fields of industry, from a wide variety of
backgrounds, countries, cultures and customs, *should* be as professional
and neutral as possible. It *should* be "boring and bureaucratic".

When you write things like

"I'd suggest printing out a copy of the GNU coding standards, and NOT
read it. Burn them, it's a great symbolic gesture"

or

"Encoding the type of a function into the name (so-called Hungarian
notation) is brain damaged [...] No wonder MicroSoft makes buggy programs"

the only thing you are doing is alienating people. (And those are just
two examples of many.) Also, how many big respectable international
corporations would put this kind of language in their official
documentation for the wider public?

The Linux kernel is not a small hobby project for some small group of
nerds anymore. It hasn't been for like a couple decades now. And it
isn't even intended to be. The very coding style document itself
advocates for the use of Linux (over other OS's like Windows), and
clearly would want to be as widely used as possible. Thus, it makes
absolutely no sense to use unprofessional cringe and alienating
language like that in an official document intended for the wider
public.

Imagine going to some giant megacorporation to try to sell some idea
or product of yours, and in your presentation you used language
like that.

[Mut...@dastardlyhq.com]

On Fri, 16 Sep 2022 06:02:12 -0000 (UTC)
Juha Nieminen <nos...@thanks.invalid> wrote:
>Michael S <already...@yahoo.com> wrote:
>>> Just read the cringe language used in the *official* Linux kernel coding
>>> style guideline page:
>>> https://www.kernel.org/doc/html/v4.10/process/coding-style.html
>>>
>>
>> I like the language of this text.
>> Style itself - less so; agree or accept with 80%, but not with another 20%.
>> It seems, what you consider "professional language" I'd consider boring
>> and bureaucratic. Or, may be, not. In order to know for sure you have to
>> give me an example of what you consider well-written style guide.
>
>An official documentation intended for use by companies and individual
>people from all around the world, both hobbyists and professionals,
>from a wide variety of fields of industry, from a wide variety of
>backgrounds, countries, cultures and customs, *should* be as professional
>and neutral as possible. It *should* be "boring and bureaucratic".

Bollocks. A lot of the people writing linux code are hobbiests and if you
want to attract those sorts of people a light hearted approach is a good
approach. The LAST thing you want is dull, tedious documentation that drones
on to the point where people just stop reading it.

>When you write things like
>
>"I'd suggest printing out a copy of the GNU coding standards, and NOT
>read it. Burn them, it's a great symbolic gesture"
>
>or
>
>"Encoding the type of a function into the name (so-called Hungarian
>notation) is brain damaged [...] No wonder MicroSoft makes buggy programs"
>
>the only thing you are doing is alienating people. (And those are just

You might be alienating some aspies with zero social skills but for most
people it'll elicit a chuckle and keep them reading.

>two examples of many.) Also, how many big respectable international
>corporations would put this kind of language in their official
>documentation for the wider public?

You're confusing business products with an open source project. One you pay
for, one you don't.

>The Linux kernel is not a small hobby project for some small group of
>nerds anymore. It hasn't been for like a couple decades now. And it
>isn't even intended to be. The very coding style document itself

Except plenty of people who work on the kernel ARE hobbyists.

>advocates for the use of Linux (over other OS's like Windows), and
>clearly would want to be as widely used as possible. Thus, it makes
>absolutely no sense to use unprofessional cringe and alienating
>language like that in an official document intended for the wider
>public.
>
>Imagine going to some giant megacorporation to try to sell some idea
>or product of yours, and in your presentation you used language
>like that.

Oh do bore off.

[Juha Nieminen]

Mut...@dastardlyhq.com wrote:
>>An official documentation intended for use by companies and individual
>>people from all around the world, both hobbyists and professionals,
>>from a wide variety of fields of industry, from a wide variety of
>>backgrounds, countries, cultures and customs, *should* be as professional
>>and neutral as possible. It *should* be "boring and bureaucratic".
>
> Bollocks. A lot of the people writing linux code are hobbiests and if you
> want to attract those sorts of people a light hearted approach is a good
> approach. The LAST thing you want is dull, tedious documentation that drones
> on to the point where people just stop reading it.

The majority of current contributors to the Linux kernel are giant
international megacorporations (including companies like Intel,
Google, Huawei, Red Hat, Linaro, Samsung and IBM). Hobbyists are *not*
the majority of contributors, and haven't been for quite a while.

Even then, I have really hard time believing that some hobbyist would
decide not to contribute to the Linux kernel because its code style
guideline page uses neutral to-the-point professional language. I find
the opposite notion to be bizarre and silly.

The contrary may well be true: Someone may find the infantile tone of
such documentation disgraceful and unprofessional, and dismiss the whole
thing as just a toy project.

>> Also, how many big respectable international
>>corporations would put this kind of language in their official
>>documentation for the wider public?
>
> You're confusing business products with an open source project. One you pay
> for, one you don't.

This has nothing to do with price. Linux *is* a business project, like
it or not. Just because it doesn't cost anything doesn't change that
fact. (Tons of corporations have business offering products for free,
such as Google, Microsoft and others.)

But even if it weren't, using infantile cringle language that's likely
to just alienate people makes no sense, no matter how "open source"
the project may be.

I don't even understand why you are defending that web page. It makes
no sense.

[David Brown]

On 16/09/2022 12:37, Mut...@dastardlyhq.com wrote:
> On Fri, 16 Sep 2022 06:02:12 -0000 (UTC)
> Juha Nieminen <nos...@thanks.invalid> wrote:
>> Michael S <already...@yahoo.com> wrote:
>>>> Just read the cringe language used in the *official* Linux kernel coding
>>>> style guideline page:
>>>> https://www.kernel.org/doc/html/v4.10/process/coding-style.html
>>>>
>>>
>>> I like the language of this text.
>>> Style itself - less so; agree or accept with 80%, but not with another 20%.
>>> It seems, what you consider "professional language" I'd consider boring
>>> and bureaucratic. Or, may be, not. In order to know for sure you have to
>>> give me an example of what you consider well-written style guide.
>>
>> An official documentation intended for use by companies and individual
>> people from all around the world, both hobbyists and professionals,
>>from a wide variety of fields of industry, from a wide variety of
>> backgrounds, countries, cultures and customs, *should* be as professional
>> and neutral as possible. It *should* be "boring and bureaucratic".
>
> Bollocks. A lot of the people writing linux code are hobbiests and if you
> want to attract those sorts of people a light hearted approach is a good
> approach. The LAST thing you want is dull, tedious documentation that drones
> on to the point where people just stop reading it.
>

It is possible to be light-hearted while remaining professional.

It is /decades/ since the core of Linux development was done by hobby
programmers. The great majority of the work on the kernel, excluding
support for more obscure hardware, is done by people who are paid to
write the code.

It is important for the project that "small" programmers don't feel
alienated, or that it is too bureaucratic, but it is also important to
remember it is a professional project, run by professionals, and used by
professionals.

Fortunately, the style guide here is something only the actual technical
coders will look at - and even then, most contributors will copy the
existing code style rather than looking at the guide. They are much
more likely to laugh at it than "corporate leader" types who might
wonder if this is the kind of project they can bet their company's
future on.

It's worth noting that Linus Torvalds has gradually developed a more
mature, diplomatic and professional style of leadership and of
communication with the outside world, while still maintaining a unique
development environment. I would expect that sooner or later, this
guide will also get cleaned up (as well as being modernised to include
C11, now that it is the standard for the kernel).

>> When you write things like
>>
>> "I'd suggest printing out a copy of the GNU coding standards, and NOT
>> read it. Burn them, it's a great symbolic gesture"
>>
>> or
>>
>> "Encoding the type of a function into the name (so-called Hungarian
>> notation) is brain damaged [...] No wonder MicroSoft makes buggy programs"
>>
>> the only thing you are doing is alienating people. (And those are just
>
> You might be alienating some aspies with zero social skills but for most
> people it'll elicit a chuckle and keep them reading.
>
>> two examples of many.) Also, how many big respectable international
>> corporations would put this kind of language in their official
>> documentation for the wider public?
>
> You're confusing business products with an open source project. One you pay
> for, one you don't.
>

Much of the Linux world is professional and paid-for. When you buy a
server from IBM with Red Hat Linux, you pay a /lot/. Linux is not
driven by zero-cost usage of software written by people for free. Open
source is not primarily about zero cost (though the fact that you can
use it for zero cost hugely increases its popularity) - it is about an
open development model, and sharing the cost and sharing the results.

>> The Linux kernel is not a small hobby project for some small group of
>> nerds anymore. It hasn't been for like a couple decades now. And it
>> isn't even intended to be. The very coding style document itself
>
> Except plenty of people who work on the kernel ARE hobbyists.
>

They outnumber the professionals in terms of numbers of contributors -
but the professionals outnumber the hobbyists in terms of the work done
and code committed. And if you look at in terms of the key parts of the
kernel, used by everyone, the difference is vastly greater.

The style of this coding guide was fine when it was written, but the
Linux project has moved on and changed enormously since then. I doubt
if it has caused much real negative reaction in practice, but it is
certainly due for an update.

[Mut...@dastardlyhq.com]

On Fri, 16 Sep 2022 11:05:50 -0000 (UTC)
Juha Nieminen <nos...@thanks.invalid> wrote:
>Mut...@dastardlyhq.com wrote:
>>>An official documentation intended for use by companies and individual
>>>people from all around the world, both hobbyists and professionals,
>>>from a wide variety of fields of industry, from a wide variety of
>>>backgrounds, countries, cultures and customs, *should* be as professional
>>>and neutral as possible. It *should* be "boring and bureaucratic".
>>
>> Bollocks. A lot of the people writing linux code are hobbiests and if you
>> want to attract those sorts of people a light hearted approach is a good
>> approach. The LAST thing you want is dull, tedious documentation that drones
>> on to the point where people just stop reading it.
>
>The majority of current contributors to the Linux kernel are giant
>international megacorporations (including companies like Intel,
>Google, Huawei, Red Hat, Linaro, Samsung and IBM). Hobbyists are *not*
>the majority of contributors, and haven't been for quite a while.

You'll have some stats to back that up then.

>Even then, I have really hard time believing that some hobbyist would
>decide not to contribute to the Linux kernel because its code style
>guideline page uses neutral to-the-point professional language. I find
>the opposite notion to be bizarre and silly.

People don't contribute because they have to but because they want to. Even
most of the ones employed to do it will have probably started out doing it as a
hobby because you don't just hire someone to do kernel development when
they've never done it before.

>The contrary may well be true: Someone may find the infantile tone of
>such documentation disgraceful and unprofessional, and dismiss the whole
>thing as just a toy project.

Its not infantile, its just tongue in cheek. Plenty of the Dummies Guide books
have the same approach and they sell by the bucket load.

>>> Also, how many big respectable international
>>>corporations would put this kind of language in their official
>>>documentation for the wider public?
>>
>> You're confusing business products with an open source project. One you pay
>> for, one you don't.
>
>This has nothing to do with price. Linux *is* a business project, like

The linux kernel which we're discussing is NOT a business project. If a
corporation wants to add to it or package it up into a distro and sell that
thats up to them, but the kernel is not and never has been a business project.

>it or not. Just because it doesn't cost anything doesn't change that
>fact. (Tons of corporations have business offering products for free,
>such as Google, Microsoft and others.)

It value adds what they already have or nudges people into their ecosystem.
How does the linux kernel do that?

>I don't even understand why you are defending that web page. It makes
>no sense.

Its clear you have zero sense of humour so there appears to be little point
arguing the toss with you.

[Tim Rentsch]

Michael S <already...@yahoo.com> writes:

> On Wednesday, September 14, 2022, Juha Nieminen wrote:
>
>> Andreas Kempe <ke...@lysator.liu.se> wrote:
>>
>>> This might be part of the reasoning, but I think the main reason
>>> is that Linus is biased against C++ on the grounds of simply not
>>> liking the language.
>>>
>>> Here's a quote I managed to find again from when they were
>>> discussing Rust support in the kernel:
>>
>> I still find it astonishing how much unprofessionalism there is
>> in the Linux development scene, even at the highest levels.
>>
>> Just read the cringe language used in the *official* Linux kernel
>> coding style guideline page:
>> https://www.kernel.org/doc/html/v4.10/process/coding-style.html
>>
>> (I'm not talking about the coding style itself, but the
>> explanatory text.)
>
> I like the language of this text.
> Style itself - less so; agree or accept with 80%, but not with
> another 20%.

Do you mind saying which parts you don't agree with?

[David Brown]

On 16/09/2022 15:18, Mut...@dastardlyhq.com wrote:
> On Fri, 16 Sep 2022 11:05:50 -0000 (UTC)
> Juha Nieminen <nos...@thanks.invalid> wrote:
>> Mut...@dastardlyhq.com wrote:
>>>> An official documentation intended for use by companies and individual
>>>> people from all around the world, both hobbyists and professionals,
>>> >from a wide variety of fields of industry, from a wide variety of
>>>> backgrounds, countries, cultures and customs, *should* be as professional
>>>> and neutral as possible. It *should* be "boring and bureaucratic".
>>>
>>> Bollocks. A lot of the people writing linux code are hobbiests and if you
>>> want to attract those sorts of people a light hearted approach is a good
>>> approach. The LAST thing you want is dull, tedious documentation that drones
>>> on to the point where people just stop reading it.
>>
>> The majority of current contributors to the Linux kernel are giant
>> international megacorporations (including companies like Intel,
>> Google, Huawei, Red Hat, Linaro, Samsung and IBM). Hobbyists are *not*
>> the majority of contributors, and haven't been for quite a while.
>
> You'll have some stats to back that up then.

There is a marvellous tool called "google" that can help you avoid
making a fool of yourself in public. But to help you out :

<https://en.wikipedia.org/wiki/Linux#Community>

"""
Although Linux distributions are generally available without charge,
several large corporations sell, support, and contribute to the
development of the components of the system and of free software. An
analysis of the Linux kernel in 2017 showed that well over 85% of the
code developed by programmers who are being paid for their work, leaving
about 8.2% to unpaid developers and 4.1% unclassified.[97] Some of the
major corporations that provide contributions include Intel, Samsung,
Google, AMD, Oracle and Facebook.[98] A number of corporations, notably
Red Hat, Canonical and SUSE, have built a significant business around
Linux distributions.
"""

(I'm sure you are now tempted to make pathetic claims about Wikipedia
being wrong - but I'd encourage you to follow the references in the
Wikipedia article, and search yourself, before doing so.)


<https://lwn.net/Articles/839772/>

That puts the number of lines changed for Linux 5.10 at 4% for people
contributing without it being via their employer, and 5.3% for
"unknown". Thus 90.7% of the changes come from known corporate sources
or other employers (such as universities).

Other links:

<https://www.linux.com/news/who-contributes-linux-kernel/>


(I've snipped the rest of your post, since you are writing out of
complete ignorance or denial about Linux. Ignorance is easily cured, if
you are willing to accept the cure - read the links, and research
yourself for more information that is wildly off-topic for this group.)

>> I don't even understand why you are defending that web page. It makes
>> no sense.
>
> Its clear you have zero sense of humour so there appears to be little point
> arguing the toss with you.
>

I can't answer for Juha's sense of humour, but he is spot-on about how
and by whom Linux is developed and how the development is paid for, and
how it is a professional project. And I suspect he is well aware of the
difference between "light-hearted with a bit of humour" and the language
used in the kernel style guide. College student level jokes are fine
between college students - they are inappropriate for a professional and
serious project.

[Scott Lurndal]

I think one should always use braces for if/while/do/for
regardless of the number of statements in the construct.

Perhaps this comes from my punched card days, when adding
a statement to the if would have required repunching the if
statement card if it hadn't used braces from the beginning,
but it also does help avoid future problems during maintenance
or enhancement activities.

And I disagree with the 8 column hard tabs. As tabs were
derived from mechanical typewriters, where the tabs were
always variable, their rationale for 8 column tabs isn't compelling.

I disagree with their opinion on typedefs (for C; for C++ since
you don't need the struct/class keywords, the class/struct name
doesn't need a typedef).

I've been working on Linux kernel code off-and-on since 1997, including
contributing an in-kernel debugger (kdb) in 1998/9 while at SGI.

[David Brown]

On 16/09/2022 16:29, Scott Lurndal wrote:
> Tim Rentsch <tr.1...@z991.linuxsc.com> writes:
>> Michael S <already...@yahoo.com> writes:
>>
>>> On Wednesday, September 14, 2022, Juha Nieminen wrote:
>>>
>>>> Andreas Kempe <ke...@lysator.liu.se> wrote:
>>>>
>>>>> This might be part of the reasoning, but I think the main reason
>>>>> is that Linus is biased against C++ on the grounds of simply not
>>>>> liking the language.
>>>>>
>>>>> Here's a quote I managed to find again from when they were
>>>>> discussing Rust support in the kernel:
>>>>
>>>> I still find it astonishing how much unprofessionalism there is
>>>> in the Linux development scene, even at the highest levels.
>>>>
>>>> Just read the cringe language used in the *official* Linux kernel
>>>> coding style guideline page:
>>>> https://www.kernel.org/doc/html/v4.10/process/coding-style.html
>>>>
>>>> (I'm not talking about the coding style itself, but the
>>>> explanatory text.)
>>>
>>> I like the language of this text.
>>> Style itself - less so; agree or accept with 80%, but not with
>>> another 20%.
>>
>> Do you mind saying which parts you don't agree with?
>
> I think one should always use braces for if/while/do/for
> regardless of the number of statements in the construct.
>

I agree.

> Perhaps this comes from my punched card days, when adding
> a statement to the if would have required repunching the if
> statement card if it hadn't used braces from the beginning,
> but it also does help avoid future problems during maintenance
> or enhancement activities.

My reasoning is that braces reduces the risk for errors - both while
writing code, and when reading it. As well as the well-known issue of
multi-statement macros (which should have a "do {...} while (0)" wrapper
anyway), it improves consistency. An open brace means the next line has
an extra indent, unindents have a close brace - and vice versa. This
makes it much easier to see the nesting and scope.

In addition, the kernel coding style rule requires:

if (condition)
do_this();
else
do_that();

and

if (condition) {
do_this();
do_more();
} else {
do_that();
}

This means adding the line "do_more()" changes another three lines that
are not semantically affected, simply to suit the style. That's bad
practice, especially for a project where revision control and changesets
are so critical - you do not want cosmetic changes on unrelated code.

I am okay with simple conditionals and a simple statement on the same
line without braces, as long as things are very clear :

if (!p_data) return; // No data, so nothing to do

if (x > max_value) x = max_value;

>
> And I disagree with the 8 column hard tabs. As tabs were
> derived from mechanical typewriters, where the tabs were
> always variable, their rationale for 8 column tabs isn't compelling.
>

Agreed. I usually use 4 spaces for a tab, although it is really just a
personal preference. I agree with the guide that many indentation
levels is a sign that your function is probably due for a refactoring,
but you don't have to have such big tabs to see that.

> I disagree with their opinion on typedefs (for C; for C++ since
> you don't need the struct/class keywords, the class/struct name
> doesn't need a typedef).

I don't agree with the guide on typedefs either, though that does not
necessarily mean we disagree in the same way about the same details!

Some of the factors in any coding style guide are going to be dependent
on characteristics of the project - rules that suit a single-person
project will not always match with one spanning hundreds or thousands of
developers. Similarly portability, project size, target system,
language standards, and all kinds of other factors come into play.
Disagreeing about a particular style guide point does not necessarily
mean I think it is /wrong/, merely that I typically follow different rules.

>
> I've been working on Linux kernel code off-and-on since 1997, including
> contributing an in-kernel debugger (kdb) in 1998/9 while at SGI.

Quiet - don't spoil people's delusions by telling them corporations
contribute to Linux!

[Mut...@dastardlyhq.com]

On Fri, 16 Sep 2022 16:00:41 +0200
David Brown <david...@hesbynett.no> wrote:
>On 16/09/2022 15:18, Mut...@dastardlyhq.com wrote:
>> On Fri, 16 Sep 2022 11:05:50 -0000 (UTC)
>> Juha Nieminen <nos...@thanks.invalid> wrote:
>>> Mut...@dastardlyhq.com wrote:
>>>>> An official documentation intended for use by companies and individual
>>>>> people from all around the world, both hobbyists and professionals,
>>>> >from a wide variety of fields of industry, from a wide variety of
>>>>> backgrounds, countries, cultures and customs, *should* be as professional
>>>>> and neutral as possible. It *should* be "boring and bureaucratic".
>>>>
>>>> Bollocks. A lot of the people writing linux code are hobbiests and if you
>>>> want to attract those sorts of people a light hearted approach is a good
>>>> approach. The LAST thing you want is dull, tedious documentation that
>drones
>>>> on to the point where people just stop reading it.
>>>
>>> The majority of current contributors to the Linux kernel are giant
>>> international megacorporations (including companies like Intel,
>>> Google, Huawei, Red Hat, Linaro, Samsung and IBM). Hobbyists are *not*
>>> the majority of contributors, and haven't been for quite a while.
>>
>> You'll have some stats to back that up then.
>
>There is a marvellous tool called "google" that can help you avoid
>making a fool of yourself in public. But to help you out :

Thanks for that, never thought of it.

>That puts the number of lines changed for Linux 5.10 at 4% for people
>contributing without it being via their employer, and 5.3% for
>"unknown". Thus 90.7% of the changes come from known corporate sources
>or other employers (such as universities).

Thats not the same as 90% in total over the decades. I suspect its rather
smaller.

>>> I don't even understand why you are defending that web page. It makes
>>> no sense.
>>
>> Its clear you have zero sense of humour so there appears to be little point
>> arguing the toss with you.
>>
>
>I can't answer for Juha's sense of humour, but he is spot-on about how
>and by whom Linux is developed and how the development is paid for, and
>how it is a professional project. And I suspect he is well aware of the
>difference between "light-hearted with a bit of humour" and the language
>used in the kernel style guide. College student level jokes are fine
>between college students - they are inappropriate for a professional and
>serious project.

Both you and Juha are humourless bores and in your case one who takes himself
far too seriously. People who cling on to professionalism as some kind of
badge are usually making up for a lack of actual skills.

[Michael S]

Yes, I do.

[Tim Rentsch]

In that case do you mind saying which parts you agree with?

Just kidding.. I respect your decision not to answer,
and say thank you for responding.

[Chris M. Thomasson]

[...]

The WinNt 4 kernel, yes its in C... ;^)

https://github.com/ZoloZiak/WinNT4/tree/master/private/ntos

How many bugs can you find? There has to be some in them there hills....?

;)

[Andreas Kempe]

I guess the term embedded is a bit diluted these days with how
powerful SoCs have become.

Working on projects for very small processors, I've only used C or
assembly and my main experience is using PICs. I have toyed with the
idea of using C++, but there isn't really any free C++ compilers PICs
as far as I've found.

Thank you for an informative reply!

>[...]

[Lynn McGuire]

What is a PIC ?

Lynn

[Scott Lurndal]

15 seconds with google "programming a PIC" gets you here:

https://en.wikipedia.org/wiki/PIC_microcontrollers

[Andreas Kempe]

A Wikipedia link has been provided, but I think it courteous to
explain what I meant here on Usenet. I was referring to
microcontrollers made by Microchip that range from small 8 bit RISC
processors to larger 32 bit MIPS dittos.

Compiling C, or C++ for that matter, for the smaller 8 bit ones is
quite interesting since they don't have a stack on which to push and
pop values. The stack is an automatically managed fix-depth callstack
only and the chip automatically pushes and pops return addresses when
calling and returning from functions.

I enjoy the smaller 8 bit PICs for their small instruction set where
all instructions except for branching take the same amount of time,
making timing code pretty easy to write. The bad thing is that there
is, to my knowledge, no good open source compiler, although the basic
Microchip C compiler is free as in free beer.

// Andreas Kempe

[David Brown]

Since you claim to be familiar with Google, I'll let you do your own
research here into how long Linux development contributions have been
dominated by people paid to do the work - including how long Linus
Torvalds has been paid for his efforts. You might also look at how the
lines of code in the kernel have grown, and then you can get an idea of
how much of the kernel is written by people paid by their employers to
do the work.

It is probably smaller than 90%, since that is the figure for the
changes to Linux 5.10. (Actually, the figure is 90% to 95% - unknown is
unknown.) It would be very difficult to establish a true figure for the
total of the kernel source as it is now, as parts have been re-written
or replaced many times. But I think there is little doubt that it is
made primarily by people who are paid to do the work. (The same applies
to many other major open source projects, such as gcc and clang.)

>
>>>> I don't even understand why you are defending that web page. It makes
>>>> no sense.
>>>
>>> Its clear you have zero sense of humour so there appears to be little point
>>> arguing the toss with you.
>>>
>>
>> I can't answer for Juha's sense of humour, but he is spot-on about how
>> and by whom Linux is developed and how the development is paid for, and
>> how it is a professional project. And I suspect he is well aware of the
>> difference between "light-hearted with a bit of humour" and the language
>> used in the kernel style guide. College student level jokes are fine
>> between college students - they are inappropriate for a professional and
>> serious project.
>
> Both you and Juha are humourless bores and in your case one who takes himself
> far too seriously. People who cling on to professionalism as some kind of
> badge are usually making up for a lack of actual skills.
>

People who can't distinguish between serious, professional work (or
indeed serious amateur work) and overgrown teenager attitudes are a bane
to society. Documents like that guide are not light-hearted or
entertaining in a workplace - they are an embarrassment. It's fine to
post that kind of humour as a joke, but not as a requirement for real work.

[David Brown]

Yes, indeed. There have always been powerful embedded systems, with big
processors running big OS's, but they used to be very much in the
minority. Now you can put a Pi Zero running Linux in anything. The key
distinction, I think, whether the system is running a single statically
linked program as its main task (either bare bones, or with an RTOS of
some kind).

>
> Working on projects for very small processors, I've only used C or
> assembly and my main experience is using PICs. I have toyed with the
> idea of using C++, but there isn't really any free C++ compilers PICs
> as far as I've found.
>

The PICs (and by that I assume you mean the 8-bit devices, not the PIC32
chips which have MIPS cores) have always had quite limited tools - they
are not well suited to C coding, never mind C++. The only 8-bit
microcontroller for which C++ is a reasonable option is the AVR, for
which the most common compiler is gcc. The core language is well
supported, but much of the library is very limited - including
language-support code for things like exceptions.

[David Brown]

On 16/09/2022 23:55, Lynn McGuire wrote:

>
> What is a PIC ?
>

Ignorance is bliss - you'd have been happier if you never knew :-)

Since Scott has already posted a link, I think the key thing to know is
that it is one of the most brain-dead of all the brain-dead 8-bit CISC
microcontroller architectures around. It makes the 8051 look smart. We
are talking single register, banked ram and flash/rom access, separate
memory spaces for code and data, an assembly language that reminds me of
microcoding rather than assembly code, hardware return stack of limited
size, very limited and highly inefficient indirect memory access instead
of pointers. There have been a number of C compilers for the chips,
each of which has its own range of non-standard features, extensions and
limitations necessary to get usable results out of the device. The
official compiler supplied (at a high cost) by the manufacturer at one
time supported structs, and arrays, but not arrays of structs or structs
containing arrays.

On the other hand, the manufacturer never stops making devices - even
when they are decades out of date, you can still buy them. That kind of
long-term availability is very rare in the business.

And the microcontrollers are incredibly robust. I've seen PIC
microcontrollers rated for 85 °C run happily at 160 °C. Short-circuits,
over-voltages, and all kinds of hardship that would kill a lesser
microcontroller rarely bother PICs. And they are popular with hobby
users as they are available in packages with big legs that are easy to
solder at home.

[Juha Nieminen]

David Brown <david...@hesbynett.no> wrote:
> People who can't distinguish between serious, professional work (or
> indeed serious amateur work) and overgrown teenager attitudes are a bane
> to society. Documents like that guide are not light-hearted or
> entertaining in a workplace - they are an embarrassment. It's fine to
> post that kind of humour as a joke, but not as a requirement for real work.

I have seriously entertained the idea of contacting the people maintaining
the kernel website and offering to reword that page to use a more neutral
and professional language (just the exaplantory text, not the code examples
themselves).

However, I don't think it's worth the effort to even contact them because
I'm somewhat certain of what their answer will be. Something along the
lines of "the page is fine as it is, there's no need to change it."
And I wouldn't be surprised if there was some slight mockery in the
response. (And that's assuming I would get any response at all.)

[Juha Nieminen]

David Brown <david...@hesbynett.no> wrote:
> (as well as being modernised to include
> C11, now that it is the standard for the kernel).

Speaking of which, I find it a bit surprising that there seems to be no
official rule, directive or even recommendation on which version of C
can/should be used in kernel code. Or at least I can't find this anywhere
(I have tried).

The only thing I have found is some directive/rule that the kernel has
to compile with gcc 3.3, but AFAIK even that rule is old and obsolete
(and the current kernel might not compile with that version of gcc
anymore.)

[Juha Nieminen]

Andreas Kempe <ke...@lysator.liu.se> wrote:
> I enjoy the smaller 8 bit PICs for their small instruction set where
> all instructions except for branching take the same amount of time,
> making timing code pretty easy to write. The bad thing is that there
> is, to my knowledge, no good open source compiler, although the basic
> Microchip C compiler is free as in free beer.

I suppose sdcc is *the* C compiler for 8-bit CPUs, although their webpage
states that "Microchip PIC16 and PIC18 targets are unmaintained" (which
I don't know if it means that you can't compile for them, or just that
there might be bugs or inefficiencies.)

Not that sdcc is an extraordinarily good compiler (it's quite bad at
optimizing for size or speed. For example it will often load the same
value from memory to a register several times for several consecutive
operations because the optimizer is unable to see that the value was
already loaded to that register and hasn't changed.)

[Juha Nieminen]

David Brown <david...@hesbynett.no> wrote:
>> I guess the term embedded is a bit diluted these days with how
>> powerful SoCs have become.
>
> Yes, indeed. There have always been powerful embedded systems, with big
> processors running big OS's, but they used to be very much in the
> minority. Now you can put a Pi Zero running Linux in anything. The key
> distinction, I think, whether the system is running a single statically
> linked program as its main task (either bare bones, or with an RTOS of
> some kind).

There are still tons of devices which use processors so small that it
wouldn't make any sense to have Linux running in them, just for them
to blink some leds and update some LCD, or act as a watchdog. Price
and power consumption (and sometimes even physical size) play important
roles here.

[David Brown]

We use such microcontrollers all the time. Note that there are /many/
advantages of them - not just price, power and size. There are complete
Linux SOMs available that are smaller and cheaper (and not much more
power) than some of the microcontrollers I use, but the microcontrollers
are still the better choice by a long way.

In terms of counts of devices shipped, processors that are capable of
running an OS like Linux are a negligible rounding error compared to
microcontrollers.

(Mind you, someone managed to get Linux running on an 8-bit AVR
microcontroller...
<http://dangerousprototypes.com/blog/2012/03/29/running-linux-on-a-8bit-avr/>
)

[Mut...@dastardlyhq.com]

On Sun, 18 Sep 2022 12:13:51 +0200
David Brown <david...@hesbynett.no> wrote:

>On 16/09/2022 17:16, Mut...@dastardlyhq.com wrote:
>> Both you and Juha are humourless bores and in your case one who takes himself
>
>> far too seriously. People who cling on to professionalism as some kind of
>> badge are usually making up for a lack of actual skills.
>>
>
>People who can't distinguish between serious, professional work (or
>indeed serious amateur work) and overgrown teenager attitudes are a bane
>to society. Documents like that guide are not light-hearted or
>entertaining in a workplace - they are an embarrassment. It's fine to
>post that kind of humour as a joke, but not as a requirement for real work.

Like I said, you're a humourless bore, you didn't need to prove it yet again.
If you're a manager god help your team, they must dread any meetings they
have to suffer with you.

[Juha Nieminen]

Mut...@dastardlyhq.com wrote:
> Like I said, you're a humourless bore, you didn't need to prove it yet again.
> If you're a manager god help your team, they must dread any meetings they
> have to suffer with you.

You do understand that's not an argument against the notion that official
kernel documentation should be more professional in tone and style?

[David Brown]

I think you are overestimating him by questioning if he understands
anything at all. And we can be very confident that even if he has
actually learned anything from the information he has been given, he
will not admit it.

[Mut...@dastardlyhq.com]

On Mon, 19 Sep 2022 13:48:29 +0200
David Brown <david...@hesbynett.no> wrote:
>On 19/09/2022 12:41, Juha Nieminen wrote:
>> Mut...@dastardlyhq.com wrote:
>>> Like I said, you're a humourless bore, you didn't need to prove it yet
>again.
>>> If you're a manager god help your team, they must dread any meetings they
>>> have to suffer with you.
>>
>> You do understand that's not an argument against the notion that official
>> kernel documentation should be more professional in tone and style?
>
>I think you are overestimating him by questioning if he understands
>anything at all. And we can be very confident that even if he has

Humourless AND arrogant.

>actually learned anything from the information he has been given, he
>will not admit it.

Why would I change my opinion? The kernel is not a company product, its OSS
and the tone can be whatever Linus wants. If you don't like it thats your
problem, not his. I'm sure the Windows documentation is very professional.
Shame about the OS.

[Keith Thompson]

https://www.kernel.org/doc/html/latest/process/programming-language.html

The kernel is written in the C programming language [c-language].
More precisely, the kernel is typically compiled with gcc [gcc]
under -std=gnu11 [gcc-c-dialect-options]: the GNU dialect of
ISO C11. clang [clang] is also supported, see docs on Building
Linux with Clang/LLVM.

--
Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

[Juha Nieminen]

Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote:
> I should have thought the experiment was worth the effort. Memory
> errors are still a significant source of bugs and vulnerabilities, and
> the promise that, by virtue of Rust's linear/affine type system, a
> component that compiles is guaranteed to be memory correct as long as
> the unsafe subset of Rust hasn't been used is quite a strong statement.

I happened to stumble across this, which seems to contradict that notion:

https://doc.rust-lang.org/book/ch15-06-reference-cycles.html

[Richard]

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

Lynn McGuire <lynnmc...@gmail.com> spake the secret code
<tffub4$1s3f$1...@gioia.aioe.org> thusly:

>"Richard Stallman Announces C Reference"
>

>> It isn't in a common format as GNU TexInfo was used to create it.

I like a lot of the stuff that the GNU Project has done, but TexInfo
is an abomination and a failure. Nobody[*] has adopted it for use
outside of GNU projects.

[*] I'm sure someone will post a link to some dinky project that uses
it, but I'm making a statement fit for human consumption not writing
mathematical axioms.
--
"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>

[Richard]

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

Opus <ifo...@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.

[Manfred]

On 9/10/2022 7:04 PM, Scott Lurndal wrote:
> Bonita Montero <Bonita....@gmail.com> writes:

>> 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-reference.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.
>>
>
> I think you have that backwards. Really.

Definitely.

[Manfred]

On 9/12/2022 12:05 PM, Bo Persson wrote:
> On 2022-09-12 at 09:42, Bonita Montero wrote:
>> Am 12.09.2022 um 09:18 schrieb Bo Persson:
>>> On 2022-09-11 at 17:44, Mut...@dastardlyhq.com wrote:
>>>> On Sun, 11 Sep 2022 13:42:20 +0200
>>>> Bonita Montero <Bonita....@gmail.com> wrote:
>>>>> Am 11.09.2022 um 11:44 schrieb Mut...@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.
>
> It's a function only if x is a type. But x is a value, like in the int
> case, so it is a constructor call.
>

Ironically, I think this kind of proves the case.

>> This object is mostly moved from inside f( x ).
>> if f( x ) is inlined this move is optimized away.
>
> And still, the C guys cannot see what happens here. So "improve" this as
>
> struct my_class f;
> init(&f, x);
>
> And now it is suddenly obvious EXACTLY what happens?  :-)
>

:)

[Kenny McCormack]

In article <tgn3v7$1ui4$1...@gioia.aioe.org>, Manfred <non...@add.invalid> wrote:
...

>>> C is a good language to learn programming
>>> but actually not to solve real tasks.
>>>
>>
>> I think you have that backwards. Really.
>
>Definitely.

Normally, one would assume that the first text quoted above was just a typo
or a cut-and-paste error or something like that.

But you should note who wrote it. Bonita is an unabashed C++ promoter and C
basher (and general, all around, lunatic). It was intended as written.

--
"The party of Lincoln has become the party of John Wilkes Booth."

- Carlos Alazraqui -

[Bonita Montero]

Am 24.09.2022 um 17:54 schrieb Kenny McCormack:
> In article <tgn3v7$1ui4$1...@gioia.aioe.org>, Manfred <non...@add.invalid> wrote:
> ...
>>>> C is a good language to learn programming
>>>> but actually not to solve real tasks.
>>>>
>>>
>>> I think you have that backwards. Really.
>>
>> Definitely.
>
> Normally, one would assume that the first text quoted above was just a typo
> or a cut-and-paste error or something like that.
>
> But you should note who wrote it. Bonita is an unabashed C++ promoter and C
> basher (and general, all around, lunatic). It was intended as written.

C is an outdated language. It's much likely to make mistakes with C than
with C++ or Rust f.e. and you have a magnitude more work to do the same
thing.