Add Caveats Section to fgetln(3)

[gbe]

Summary

Add a Caveats Section to fgetln(3)

Obtained from: OpenBSD

Test Plan

mandoc output review

[yuripv]

lib/libc/stdio/fgetln.3

142

Nitpicking: != NULL, per style(9), "Test pointers against NULL"

[jilles]

Although there is nothing wrong with this per se, applications can deal with this problem more easily using getline(3) (which is also standard).

[bcr]

In D24916#548579, @jilles wrote:

Although there is nothing wrong with this per se, applications can deal with this problem more easily using getline(3) (which is also standard).

We could mention this (the reference to getline(3)) in that section.

[gbe]

lib/libc/stdio/fgetln.3

142

Did you mean something like the following for the while condition?

((buf = fgetln(fp, &len)) != null)

[yuripv]

lib/libc/stdio/fgetln.3

142

Exactly, but as it's really nitpicking, feel free to ignore this comment.

[gbe]

• Add NULL pointer check for the while condition

[gbe]

In D24916#548579, @jilles wrote:

Although there is nothing wrong with this per se, applications can deal with this problem more easily using getline(3) (which is also standard).

We already .Xr getline(3). Would that be enough, or should we explicitly reference it as a better alternative in the CAVEATS section?

[gbe]

@bcr can this be committed?

[bcr]

Good to go. Thanks!

[0mp]

head/lib/libc/stdio/fgetln.3

130 ↗

(On Diff #73264)

I am pretty sure that you're going to hear voices on the mailing list saying that you should break the line after the comma in this case. ;)

134 ↗

(On Diff #73264)

s/won't/will not/

135 ↗

(On Diff #73264)

I'd put "a" into the next line.

149 ↗

(On Diff #73264)

Should we check the output of memcpy?

[0mp]

head/lib/libc/stdio/fgetln.3

132 ↗

(On Diff #73264)

Also, as per style.mdoc(5), Dq should be used here instead of Sq.

What do you think, @bcr?

[gbe]

@0mp I see that you have put a lot of comments in already approved and committed differential. Could provide just a new differential with you comments applied to manpage? I wasn't aware of style.mdoc(5), definitely read it this afternoon.

[bcr]

You can always re-open the revision.
@0mp: Sure, Dq is better. Sorry I missed that, causing extra work.

[gbe]

In D24916#558726, @bcr wrote:

You can always re-open the revision.
@0mp: Sure, Dq is better. Sorry I missed that, causing extra work.

In theory a differential can be re-opened, but dealing with an already committed one puts you in the position to personally editing the resulting diff by hand, which is, to say at least, frustrating.

[0mp]

In D24916#558733, @gbe wrote:

In D24916#558726, @bcr wrote:

You can always re-open the revision.
@0mp: Sure, Dq is better. Sorry I missed that, causing extra work.

In theory a differential can be re-opened, but dealing with an already committed one puts you in the position to personally editing the resulting diff by hand, which is, to say at least, frustrating.

Haha, obviously I've not thought for a second that you'd need to edit those diffs by hand :D That would be cruel.

I wasn't aware that this revision had been already committed when I submitted my comments. Sorry about that. If you decide to fix address those comments in another differential revision I'll be happy to review them again. When it comes to memcpy though, I'd ask a src committer for an opinion.