Page MenuHomeFreeBSD

Remove K&R stuff: never use it in new code.
ClosedPublic

Authored by imp on Jan 25 2018, 3:45 PM.
Tags
None
Referenced Files
F81975077: D14051.id40104.diff
Tue, Apr 23, 11:56 PM
Unknown Object (File)
Sat, Apr 6, 6:38 PM
Unknown Object (File)
Fri, Mar 29, 3:02 PM
Unknown Object (File)
Thu, Mar 28, 2:25 PM
Unknown Object (File)
Mar 6 2024, 5:28 AM
Unknown Object (File)
Feb 14 2024, 10:48 AM
Unknown Object (File)
Dec 23 2023, 3:48 AM
Unknown Object (File)
Nov 7 2023, 6:48 AM
Subscribers

Details

Summary

Remove how to format K&R stuff. The project hasn't been using it in
new code for a long time.

Diff Detail

Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 14579
Build 14713: arc lint + arc unit

Event Timeline

This revision is now accepted and ready to land.Jan 25 2018, 3:56 PM

Only question I have before we remove this, is the tree void of code in this format?

If it is not then I think it would be unwise to remove this,if it is then yes, absolutely, remove this.

Only question I have before we remove this, is the tree void of code in this format?

If it is not then I think it would be unwise to remove this,if it is then yes, absolutely, remove this.

There's plenty of stuff in the tree that doesn't conform to style(9). I don't we should make compliance a prerequisite to changing bits of style(9).

dab added a reviewer: dab.

Only question I have before we remove this, is the tree void of code in this format?

If it is not then I think it would be unwise to remove this,if it is then yes, absolutely, remove this.

No new code has it.
There's odd corners of the tree that may still have it, but anybody changing it would remove the K&R style and go with full ANSI, so I'm not sure I understand how it would be useful to retain.

brooks added a subscriber: brooks.

Yes please.

All K&R function declarations are style bugs. Due to incomplete compiler support for function signature checking of K&R definitions, they can easily mask real bugs (but probably don't very much in our tree).

In D14051#295081, @imp wrote:

Only question I have before we remove this, is the tree void of code in this format?

If it is not then I think it would be unwise to remove this,if it is then yes, absolutely, remove this.

No new code has it.
There's odd corners of the tree that may still have it, but anybody changing it would remove the K&R style and go with full ANSI, so I'm not sure I understand how it would be useful to retain.

As in any documentation it would be useful to retain as it documents the state of things. Though the style guide is mostly thought of as how one should write code, it is also one of how the code was written and is of use to someone reading the code to understand why somethings are in the form that they are. Committers should not be considered the only consumer of style.9.

As in any documentation it would be useful to retain as it documents the state of things. Though the style guide is mostly thought of as how one should write code, it is also one of how the code was written and is of use to someone reading the code to understand why somethings are in the form that they are.

No. That is not what style(9) is for. It's a prescriptive style document.

gad added a subscriber: gad.

(sorry for the late noise. For some odd reason, today is the first day I've been able to connect to this page, although I've tried since last Thursday. I suspect there was a problem in the browser on my machine).

This revision was automatically updated to reflect the committed changes.