Richard Stallman Announces GNU C Language Reference Manual

[Developer12]

Who am I underestimating? I know that RMS wrote large parts of at least GCC and GNU Emacs in the beginning, that he had a large influence in the creation of all versions of the GPL, and that he always cared a lot about good documentation. I think it's a pity that he wasted a good part of the last 15 years on giving uninspiring talks against proprietary software and hampering the progress of the projects he created in the first place.

Side note: Have people read up on the colossal fuckup with wikipedia? It used to be under the same licence as this reference book.....until the FSF wrote a *very* specific backdoor escape into a new version of the licence, with the express purpose of allowing the relicence of the whole of wikipedia as creative commons. Effectively conversion from GPL to BSD. Without the consent or consultation of any of the many prexisting contributors. see: https://twitter.com/marcan42/status/1376418013151338496

The FSF can and will use the "or any later version" clause to unilaterally relicence your work without your consent, should it suit their purposes. Do not include it. This is to say *nothing* of the absolute absurdity of transferring the copyright of your work to them, which they demand for many GNU projects.

The bottom line: Don't trust the FSF to do what's right, don't trust Stallman to do what's right. They are not incorruptible and concentrating all power over free software in one place was a Bad Fucking Idea from the start.

[DavidBrown]

It's a lot more than that.

There an entire chapter in the GCC manual on its nonstandard C extensions:

https://gcc.gnu.org/onlinedocs/gcc-1...xtensions.html

Attributes & builtins I've wrapped with macros, where & when I've needed to care about portability.

Yes, I know there are many extensions listed there - I was giving some examples, not an exhaustive list. A substantial proportion of the extensions are now part of current (or planned C23) ISO C standards, but were GCC extensions when they were first implemented. They are GCC extensions when used with earlier standards, but standard C when used with newer standards. There are also plenty of extensions which are highly unlikely ever to be standardised, and some that are standardised in different ways (such as "attributes", which are coming to C23 but with a different syntax).

[baka0815]

Is it a good idea to promote languages with automatic garbage collection first?
I know the intention behind it (I think), but once you comfortable with automatic gc you may forget to manually free your memory with languages that don't have auto gc.

[coder]

Typical GCC extensions are the

__attribute__

annotations, inline assembly,

__builtin_

functions, etc.

It's a lot more than that.

There an entire chapter in the GCC manual on its nonstandard C extensions:

https://gcc.gnu.org/onlinedocs/gcc-1...xtensions.html

These are extremely useful features, especially for efficient and safe code, and often "portable enough" simply because many other compilers support them. Very few people need to write fully portable C code, and if your code needs to combine portability with the benefits of GCC extensions, then you can use conditional compilation and macros to support multiple compilers.

Attributes & builtins I've wrapped with macros, where & when I've needed to care about portability.

[DavidBrown]

Not to disagree with your sentiment, but doesn't clang support pretty much all of GCC's extensions?

Yes, clang supports most of them - and many other mainstream compilers (including some proprietary embedded compilers) support several GCC extensions. There is a strong history of popular GCC extensions being standardised in later C language standards, since the C standards committee prefer to add features that have been tried and tested in one or more major implementations.

About the only common C compiler that does not follow GCC for its extensions, is MSVC. But MSVC is well known for not bothering to support modern ISO C standards either (though I believe it is better than it used to be), and rarely considered a good C compiler. (It's much better for C++.)

Compiler devs can't avoid deciding how to implement UB, but perhaps what you mean is that it would be silly for someone to spend a lot of time documenting GCC's behavior where the standard is undefined, because users of GCC should avoid any dependencies on it.

When the C standards say something is undefined, or when they don't give a definition, it simply means that the standards don't say what will happen in those circumstances - anything can happen, including launching demons out of your nose. A particular implementation can choose to define something that the C standards leave undefined, but that is rarely what is meant by C extensions. Typical GCC extensions are the

__attribute__

annotations, inline assembly,

__builtin_

functions, etc. These are extremely useful features, especially for efficient and safe code, and often "portable enough" simply because many other compilers support them. Very few people need to write fully portable C code, and if your code needs to combine portability with the benefits of GCC extensions, then you can use conditional compilation and macros to support multiple compilers.

[Vistaus]

Can I show my age and ask: wtf is a Texi file?

Young or old age? If old, then you should know what a texi file is given that it's part of Texinfo that was first released in February 1986...

[DavidBrown]

Not being a C programmer myself, I have to ask: is a GNU C manual a good thing? On one hand, I believe ANSI C should be everybody's target. On the other hand, if GNU C follows ANSI C closely enough and the manual only explains choices made in the areas where the spec is lacking/undefined, then no harm, no foul.

If it is well written (I haven't looked at it myself), and makes it clear when code is standard or a GCC extension, then it might be a good book. There's surprisingly few good modern C books.

Be careful when talking about "ANSI C" - few people understand what it actually means. Many people think it means C89/C90, but it actually means "the latest ISO C standard", which is C17 (soon to be replaced by C23). And most people who think they are programming in C89/C90, use a variety of extensions.

GCC supports a wide range of standards, and can be instructed (via flags) to stick to the ISO standards or support its various extensions.

[coder]

Hurd is also de facto kernel and emacs the de facto text editor (or operative system, depending how you look at it)

Ouch!

Eh, most gods don't make it to the 7th day. If, Stallman only created the Sun, the Moon, and the Earth, that's still a lot. More than most of us will ever do.

Okay, so now this thread is turning out how I expected. Eh, we don't really need yet another a referendum on Stallman, do we? I'm not trying to defend him, but I think it'd be nice if his C book could be judged on its own merits.

...not that I have any notion I can actually stop this little feud, but at least I tried.

[amxfonseca]

It works with de facto compiler not some shitty m$ or llvm.

Let me guess, Hurd is also de facto kernel and emacs the de facto text editor (or operative system, depending how you look at it)

[Volta]

Obviously the harm is that you are writing GCC-only code that only works on one shitty compiler and nothing else. "Undefined behavior" in the standard doesn't mean that you can do whatever, it means that you specifically shouldn't do it at all.

It works with de facto compiler not some shitty m$ or llvm.