Page MenuHomeFreeBSD

ngctl: Modernize code somewhat
ClosedPublic

Authored by des on Thu, Feb 12, 12:35 AM.
Tags
None
Referenced Files
F145008654: D55257.id171831.diff
Sun, Feb 15, 12:14 AM
F145008597: D55257.id171829.diff
Sun, Feb 15, 12:13 AM
F144971767: D55257.id171867.diff
Sat, Feb 14, 3:20 PM
F144964136: D55257.id171829.diff
Sat, Feb 14, 1:32 PM
F144964066: D55257.id171867.diff
Sat, Feb 14, 1:32 PM
F144963952: D55257.id171831.diff
Sat, Feb 14, 1:30 PM
Unknown Object (File)
Thu, Feb 12, 2:48 PM
Unknown Object (File)
Thu, Feb 12, 12:29 PM
Subscribers

Details

Summary
  • Replace fgets(3) with getline(3)
  • Replace select(2) with poll(2)
  • Avoid needlessly copying text around
  • Correct use of getopt(3)
  • Pick some style and whitespace nits

MFC after: 1 week

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 70647
Build 67530: arc lint + arc unit

Event Timeline

des requested review of this revision.Thu, Feb 12, 12:35 AM

Tentatively seems fine, I'll do another pass tomorrow

usr.sbin/ngctl/main.c
149

This one was technically fine - style(9) allows more restrictive scoping these days, but I guess if that's not really applied anywhere else in this file we might as well push it up.

markj added inline comments.
usr.sbin/ngctl/main.c
149

It's used elsewhere in this file. I'd rather keep variables locally scoped when possible.

602

Indentation is wrong here.

This revision is now accepted and ready to land.Thu, Feb 12, 3:00 PM
This revision now requires review to proceed.Thu, Feb 12, 3:41 PM
des marked 3 inline comments as done.Fri, Feb 13, 12:00 PM
des added inline comments.
usr.sbin/ngctl/main.c
149

If you agree that style(9) allows both then please allow me to prefer the old style. It also saves vertical space by not requiring an additional blank line.

markj added inline comments.
usr.sbin/ngctl/main.c
149

And locally scoped variables reduce cognitive load when reading, by keeping declarations close to uses. But this is all subjective. The point of a style guide is to enforce some level of consistency, not to optimize for any particular metric like vertical space used. Our guide permits both styles, so here you're not fixing a bug but changing code to suit personal preferences. I prefer that we not make changes like that: they pollute git blame output and give reviewers extra things to check for no real benefit. But ok, I'm not insisting, I clicked the accept button.

This revision is now accepted and ready to land.Fri, Feb 13, 3:22 PM
This revision was automatically updated to reflect the committed changes.
des marked an inline comment as done.