[COFF] C with Improvements :-)

G. Branden Robinson g.branden.robinson at gmail.com
Mon Jun 23 13:06:03 AEST 2025


At 2025-06-22T19:06:21-0700, Larry McVoy wrote:
> The 
> 
> 	if (whatever)
> 	    {
> 	    	stmt;
> 	    }
> 
> is, I believe, GNU style and it just sucks.

Sort of.  Official GNU style is like that, but uses 2 spaces instead of
four.[1]

Fortunately for me I seldom bump my head into this issue in groff
maintenance because that project started life in C++ early on (ca.
1989), and I guess was exempted from the GNU Coding Standards due to the
different implementation language.  It mostly looks like Stroustrup's
style.  C++ was pretty young back then.  James Clark was a brave guy.

I've cracked the whip on groff's code style in other ways.[2]

> GNU C is awful.  But when I did the df/du/ls -h stuff I wrote it in
> that style, it's their house, you abide by their rules.  Fun fact,
> Stallman hated me so much he rewrote that stuff so I wasn't in their
> version history.

That could also have been the case if you didn't execute copyright
assignment paperwork.  However, GNU is no longer militant about that.[3]

Regards,
Branden

[1] https://www.gnu.org/prep/standards/standards.html#Formatting
[2] Here are some recurring themes in my commit messages.

* Mark as `static` symbols that don't need external linkage.
* Mark as `const` objects that shouldn't change.
* Spell null character using the C/C++ language literal for expressing
  it.
* Spell null pointer constant the idiomatic C++98 way (`0`) instead of
  as `NULL`.
* Reorder equality comparisons to avoid inadvertent lvalue assignment.
* Explicitly compare value of pointer type to null pointer literal
  instead of letting it pun down to a Boolean.

Except for the `const` one, you got all of these for free (or enforced
by the compiler) in Ada 83.  C's typing is so weak that I have started
calling it B++ for the sake of starting arguments^Wdiscussions.

Rust's "let mut", making you say "mut"(able) was a good idea.  Good for
concurrency.

Here's another recent gripe.

* Rename `none` enumeration constant to `none_tag` for conformity with
  other constants in the same (anonymous) enum.  C++ enums weren't
  name-spaced or properly type-checked until C++11, and C's still
  aren't.  (Ada had proper sum types back in 1983.)

Here's a GNU Coding Standards prescription I back 100%:

"When you split an expression into multiple lines, split it before an
operator, not after one."

I haven't made up my mind which style I prefer for operator overloads in
C++.  `operator+` looks ugly and `operator +` looks misleading.  Maybe
both suck, because C++ sucks.  Overloading bit shifting operators to
implement stream I/O was a repellent choice, combining an early,
somewhat understandable showboating enthusiasm for a powerful language
feature with C programmers' elitist preference for inscrutable sigils.
"foo<<bar" was hard for the novice to understand, so it was even better
for its meaning to be wholly dependent on the types of its operands.

I think a lot of the strife between the C and C++ communities arises
from C++ jockeys doing to C guys what C people had already spent years
doing to Pascal programmers--being obnoxious snobs.

While I'm making enemies, I'll emphasize that `if`, `while`, `for`, and
`switch` are not functions, so you should not jam a parenthesis up
against them.  However since these keywords always expect an expression
immediately anyway, I'm not sure historically why the expression _had_
to be parenthesized.  I suppose it made the hand-written parser easier,
but nroff, which is as old as C, does not have the same requirement.
And of course the Bourne shell and Perl don't either (AWK does, but I
assume that's to make it look like C).

Next is a practice that I disagree with, but which a former maintainer
prevailed upon me _not_ to start reforming.  I still think the status
quo will bite us in the butt one day.[4]  Still, I made this change in
the "wrong" direction because consistency is important.

* Drop braces around single-statement control flow branch; groff
  generally eschews these.

[3] https://www.gnu.org/prep/maintain/maintain.html#Copyright-Papers

[4] I manage to fix a 30+-year old bug in groff maybe a couple of times
    a year,[5] but more often I fix bugs I managed to introduce myself.
    I'm grateful to the people who run groff from the Git trunk for
    giving me opportunities to wipe the cream pie filling from my face.

[5] This one, I want stuffed and mounted.

    https://lists.gnu.org/archive/html/groff-commit/2025-05/msg00061.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://www.tuhs.org/pipermail/coff/attachments/20250622/d2269ba6/attachment.sig>


More information about the COFF mailing list