Page MenuHomeFreeBSD

copystr(9): Move to deprecate
ClosedPublic

Authored by cem on May 2 2020, 7:57 PM.
Tags
None
Referenced Files
Unknown Object (File)
Tue, Feb 11, 9:12 AM
Unknown Object (File)
Wed, Jan 29, 12:29 PM
Unknown Object (File)
Jan 17 2025, 11:49 PM
Unknown Object (File)
Jan 5 2025, 10:25 AM
Unknown Object (File)
Dec 28 2024, 4:35 PM
Unknown Object (File)
Dec 14 2024, 3:19 PM
Unknown Object (File)
Dec 10 2024, 7:09 PM
Unknown Object (File)
Nov 30 2024, 2:00 AM

Details

Reviewers
jhb
manu
Group Reviewers
Restricted Owners Package(Owns No Changed Paths)
Commits
rS361466: copystr(9): Move to deprecate (attempt #2)
rS360944: copystr(9): Move to deprecate [2/2]
Summary

Unlike the other copy*() functions, it does not serve to copy from one
address space to another or protect against potential faults. It's just
an older incarnation of the now-more-common strlcpy().

Add a coccinelle script to tools/ which can be used to mechanically
convert existing instances where replacement with strlcpy is trivial,
and apply the patch (fuse_vfsops.c and union_vfsops.c).

Replace the declaration of copystr() in systm.h with a small macro
wrapper around strlcpy.

Remove N redundant MI implementations of copystr. For MIPS, this
entailed inlining the assembler copystr into the only consumer,
copyinstr, and making the latter a LEAF function.

Test Plan

Building tinderbox

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

cem requested review of this revision.May 2 2020, 7:57 PM
share/man/man9/copy.9
72 ↗(On Diff #71293)

Should we add an "it will be removed from .Fx <whatever>"

share/man/man9/copy.9
72 ↗(On Diff #71293)

If you think so, sure. I don't have an opinion on it.

share/man/man9/copy.9
72 ↗(On Diff #71293)

You could maybe say FreeBSD 14. If we want to do it for 13, I'd say to do a single commit first with just the __deprecated tag and manpage update so that it can be merged (I can merge it) to 12.

sys/fs/fuse/fuse_vfsops.c
437 ↗(On Diff #71293)

I do wonder if this wouldn't be simpler / more efficient as:

memset(mp->mnt_stat.f_mntfromname, 0, MNAMELEN);
strlcpy(mp->mnt_stat.f_mntfromname, fspec, MNAMELEN);

You could then axe len. (I think it could be more efficient b/c the compiler can inline a statically sized memset)

sys/fs/unionfs/union_vfsops.c
307 ↗(On Diff #71293)

Maybe replace this entire few lines with:

snprintf(mp->mnt_stat.f_mntfromname, MNAMELEN, "<%s>:%s",
    below ? "below" : "above", target);

You can kill tmp, done, and len. It's also clearer (I think) as to what it is doing.

I think the MIPS bits look ok, as does the new version using strlcpy().

share/man/man9/copy.9
72 ↗(On Diff #71293)

Might as well aim for 13. The longer the timeframe, the less likely it is to actually happen. I don't envision a lot of difficulty converting out of tree consumers. Note the "deprecated" tag is only in the manual page, as my recollection is that actually adding it to the buildsystem was nonproductive.

sys/fs/fuse/fuse_vfsops.c
437 ↗(On Diff #71293)

Sure, there are any number of other ways to do this; this is just the purely mechanical coccinelle conversion. The current approach tries to avoid writing some bytes of the 1024-byte f_mntfromname twice, which the proposal deoptimizes, but I think the reduced complexity is probably worth it anyway; this is hardly a hot path.

Will change.

sys/fs/unionfs/union_vfsops.c
307 ↗(On Diff #71293)

Will do.

cem marked 4 inline comments as done.
  • Add explicit version target for removal
  • Simplify replaced invocations in fusefs, unionfs
This revision is now accepted and ready to land.May 11 2020, 9:45 PM
This revision was automatically updated to reflect the committed changes.
Owners added a reviewer: Restricted Owners Package.May 11 2020, 10:57 PM
  • Add copystr() correction from brooks. Will test.
This revision was not accepted when it landed; it landed in state Needs Review.May 25 2020, 4:41 PM
This revision was automatically updated to reflect the committed changes.