On 19.06.2025 18:03, Mark Harmstone wrote:
> On 19/06/2025 3.06 pm, Brahmajit Das wrote:
> > strcpy is deprecated due to lack of bounds checking. This patch replaces
> > strcpy with strscpy, the recommended alternative for null terminated
> > strings, to follow best practices.
>
> I think calling strcpy "deprecated" is a bit tendentious. IMHO the way to
> proceed
> is to use KASAN, which catches the misuse of strcpy as well as other bugs.
>
Understood, thanks for point it out.
> > ...snip...
>
> > --- a/fs/btrfs/volumes.c
> > +++ b/fs/btrfs/volumes.c
> > @@ -215,7 +215,7 @@ void btrfs_describe_block_groups(u64 bg_flags, char
> > *buf, u32 size_buf)
> > u32 size_bp = size_buf;
> > if (!flags) {
> > - strcpy(bp, "NONE");
> > + memcpy(bp, "NONE", 4);
> > return;
> > }
>
> These aren't equivalent. strcpy copies the source plus its trailing null - the
> equivalent would be memcpy(bp, "NONE", 4). So 4 here should really be 5 - but
> you shouldn't be hardcoding magic numbers anyway.
>
> On top of that memcpy is just as "unsafe" as strcpy, so there's no benefit to
> this particular change. gcc -O2 compiles it the same way anyway:
> https://godbolt.org/z/8fEaKTTzo
>
> Mark
>
I was planning to use strscpy, but it doesn't work with char pointers,
hence went with memcpy. If you or anyone has a better approach for this,
I'm more than happy to send that as a v3.
--
Regards,
listout
