This somewhat simplifies use of msdosfs code in userland (for makefs), and is standard C as of C89.
Details
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
There is no memcpy() in libkern. You change work because compiler inlines the function.
The common saying is that FreeBSD kernel traditionally uses bcopy().
I do not have much opinion there, but know that bde has.
Indeed - but I was surprised:
% find sys -name '*.c' | xargs cat | grep -w -c memcpy 3056 % find sys -name '*.c' | xargs cat | grep -w -c bcopy 2894
A quick grep turns up memcpy in sys/fs/ext2fs, sys/fs/devfs, sys/fs/unionfs, sys/fs/smbfs, sys/fs/cuse, sys/fs/cd9660, sys/fs/nandfs, sys/fs/autofs, sys/fs/fuse, sys/fs/tmpfs.
Most of this comes from NetBSD, perhaps except devfs and autofs. And for devfs I can see an alien code where it is used.
Anyway, I do not have opinion on this replace, as I stated.
At least one of these (bcopy(slot + WIN_CHARS, slot + count, nbp->nb_len);) has overlapping src and dst, and would have to be memmove instead.
Most of this comes from NetBSD
Our msdosfs as well, so I'll try to move this ahead.
This may unfortunately involve rehashing the memmove/memcpy symbols in kernel issue -- e.g. https://lists.freebsd.org/pipermail/freebsd-arch/2009-February/009009.html
There's no problem with either memcpy or memmove in the kernel. They just work. For like at least decade....
bcopy has 'overlapping works' semantics on at least some of our platforms, so changing to memmove is good.
While tradition is good, it's a tradition that's been more in the lapse than its observance of late.