Style(9): Strengthen statements about not using K&R function definitions

[imp]

Summary

K&R function definitions will soon be obsolete. Work has been underway
to remove all K&R function definitions from the tree for a while now. A
future C version will remove this construct from the language. So
strengthen existing statements about K&R function definitions and
declarations.

While here, remove __P macro reference. It's not been in active use for
almost two decades apart from legacy contrib code.

[• karels]

share/man/man9/style.9

798

I note that this no longer says to preserve comments about parameters in declarations; is that intentional?

[kp]

K&R C has only been obsolete since 1988. Are we sure we want to rush into this change? (/s, obviously)

[imp]

share/man/man9/style.9

798

I think you are reading this wrong.... I just uses the more proper word 'definition'. There are no parameters in a K&R declaration.

[imp]

In D35945#815990, @kp wrote:

K&R C has only been obsolete since 1988. Are we sure we want to rush into this change? (/s, obviously)

Well, maybe 2000. It took until 95 for there to be C89 compilers to be wide-spread and til 2000 or so before all the old K&R compilers were assigned to the dust bins of history as the hardware they ran on vanished...
But I guess quibbling over 12 years in where to draw the line in the past doesn't really dilute your point :)

[brooks]

One comment, but would be happy to see this land as is.

share/man/man9/style.9

797

I'd be tempted to drop all the forward-looking language and simply say they are forbidden in C23 (technically it's not ratified, but let's be realistic). It might also be worth noting something along the lines that that the latest compilers treat K&R declarations as an error for all language standards.

[imp]

Update to try to address Brooks' suggestions.

[brooks]

Works for me. The statement on compilers might be a touch strong as its only mid 2022 and later versions that do this.

[emaste]

share/man/man9/style.9

798

This is true for the latest versions of major compilers, but not versions that are still in widespread use. If we don't MFC this I think it's fine, but if we are going to MFC I think we should say "the latest versions of..." or so.

[emaste]

Pretty soon we'll be able to just remove this entirely.

[imp]

Soften statement on compilers... Is this better Brooks or should I go back?

[brooks]

This is good. As @emaste points out, we'll be able to delete this soon and attempts to bring code that does this into the tree will fail to compile.

[markm]

About time!

[pauamma_gundo.com]

share/man/man9/style.9

28

Bump.

796–799

Audience check: do all current and future FreeBSD C developers know enough C history to remember "K&R style declarations or definitions" refers to

char *foo();
double bar()
{
    return 6.62607015e-34;
}
char *foo(baz)
long baz
{
    return "quux";
}

?

(Extra-credit question; why can't I mercifully forget how those looked?)

[imp]

share/man/man9/style.9

28

Yup. With several different changes in flight, I purposefully didn't do this to avoid conflicts.

796–799

Yes. They know at least this much history.

[pauamma_gundo.com]

Looks clear and grammatical to me.

[• hselasky]

No objections.