"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.

[Thiago Adams]

I Got Permission denied
git clone https://git.savannah.gnu.org/git/c-intro-and-ref.git
fatal: could not create work tree dir 'c-intro-and-ref': Permission denied

[Kenny McCormack]

In article <f9d12d44-6d1d-44aa...@googlegroups.com>,
Thiago Adams <thiago...@gmail.com> wrote:
...

>I Got Permission denied
>git clone https://git.savannah.gnu.org/git/c-intro-and-ref.git
>fatal: could not create work tree dir 'c-intro-and-ref': Permission denied

It worked for me.

I hate to say this, but the above error message looks like a client-side
problem. What was your current directory when you ran "git"? Was
that directory writable?

--
There are two kinds of Republicans: Billionaires and suckers.
Republicans: Please check your bank account and decide which one is you.

[Keith Thompson]

That looks like a problem on your end, for example that you don't have
write access to your current directory.

--
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 */

[Scott Lurndal]

You might want to chdir to a writable directory...

[Thiago Adams]

yes the problem I was in the wrong dir.
now i have
git clone https://git.savannah.gnu.org/git/c-intro-and-ref.git
Cloning into 'c-intro-and-ref'...
fatal: unable to access 'https://git.savannah.gnu.org/git/c-intro-and-ref.git/': server certificate verification failed. CAfile: none CRLfile: none
I will wait for the pdf or html

[John Forkosh]

Kenny McCormack <gaz...@shell.xmission.com> wrote:
> In article <f9d12d44-6d1d-44aa...@googlegroups.com>,
> Thiago Adams <thiago...@gmail.com> wrote:
> ...
>>I Got Permission denied
>>git clone https://git.savannah.gnu.org/git/c-intro-and-ref.git
>>fatal: could not create work tree dir 'c-intro-and-ref': Permission denied
>
> It worked for me.

Great. So what's your (and any others') review of the book?
Worth reading? Or more importantly to me, good reference
(including good index, table-of-contents, and, of course,
good content)? I still mostly rely on my K&R2 (though still
have my even older K&R1, mostly for nostalgia).

> I hate to say this, but the above error message looks like a client-side
> problem. What was your current directory when you ran "git"? Was
> that directory writable?
--

John Forkosh ( mailto: j...@f.com where j=john and f=forkosh )

[John Forkosh]

Stefan Ram <r...@zedat.fu-berlin.de> wrote:

> John Forkosh <for...@panix.com> writes:
>>Great. So what's your (and any others') review of the book?
>

> There's a PDF in the web. I browsed it briefly.

Couldn't find it on the web. So I did what's been suggested above...
git clone https://git.savannah.gnu.org/git/c-intro-and-ref.git
cd c-intro-and-ref/
make c.pdf
So I assume that makes the same thing you're referring to.
Yeah, looks pretty good at quick first glance.

> It's obviously not intended for beginners. But when you are
> not a beginner, you will find many things in it you already
> know. So, it's less suitable as a textbook, more as a
> reference manual (which is what the author himself says).
> But, in this area, the ISO C specification is its competition!

[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.

[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.

[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.

[Tim Rentsch]

John Forkosh <for...@panix.com> writes:

> [...] what's your (and any others') review of the book?

> Worth reading? Or more importantly to me, good reference
> (including good index, table-of-contents, and, of course,
> good content)?

My reactions, fwiw...

The book is not so much about C as it is about Stallman's way of
thinking about C. If you want to think about C in the same way
that he does, this book is almost certainly the best available.
If on the other hand you want to think about C in the same way
that C is described and defined in the ISO C standard, this book
will probably be more distracting than helpful. Looking over the
book (I certainly didn't read the whole thing), my impression is
RMS can't make up his mind whether he is writing a reference, a
tutorial, or a style guide. I realize that mixing these three
aspects is common and fashionable these days when writing about
programming languages, but personally it irks me. K&R very
wisely divided its material into two parts: one, an introduction
and informal description of the language, and two, a reference.
That was an excellent choice. The current blender style of
mixing everything together is unfortunately more popular now.

Also, a low-level detail, but one worth mentioning: the layout
and formatting choices in the book, both for prose and for code,
reflect (in all likelihood) Stallman's preferences. I'm reminded
of Abraham Lincoln's comment, "For people who like this sort of
thing, this is the sort of thing that these people like."
Personally I prefer a cleaner formatting and layout style (and
yes both for code and for prose).

[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.

[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?

[Bonita Montero]

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

[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.

[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.

[John Forkosh]

Thanks for the feedback. Yeah, I overall liked the K&R style
somewhat better, too (though I haven't read RMS's thoroughly
enough, i.e., barely browsed it so far, to really have any
opinion -- "so many pdfs, so little time", I'm lucky to read
one percent of the arXiv stuff that I'd like to). Even his
First Example seemed a poor choice given its obvious tutorial
intent -- should encourage readers to focus on syntax/semantics,
whereas even simple recursion makes you think about the algorithm.

[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 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?

[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.

[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.

[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.

[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.