Richard Stallman Announces GNU C Language Reference Manual

[Delgarde]

Texinfo. It's FSF's adaptation of the TeX typesetting language for making hyperlinked reference manuals. You can think of it as their attempt to supersede man pages. Its primary client was meant to be the info browser, but I think its traction was mostly limited to Emacs users.

People like Richard Stallman, you mean? The guy responsible for both Texinfo and the most widely used version of Emacs?

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

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

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

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

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

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

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

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