On 6/15/26 09:33, Gavin Shan wrote:
Either assert n != 0 to start, or use while not do/while.
Because the body of the loop won't handle n == 0 correctly.
I will change this to "while (n > 0)" since we're not expecting
"n < 0" either.
size_t is unsigned.
Could you confirm which stores need qatomic_set()? There are two sets
of stores as below. I guess you're asking have qatomic_set() for (a)?
Could you explain a bit why qatomic_set() is needed?
// (a)
*(uint64_t *)dest = *(uint64_t *)src;
Of course (a).
Using qatomic_set prevents the compiler from merging the stores, kinda like volatile. Not
especially likely with the way you've written this, but if you had exchanged the switch
and loop,
switch (lsb) {
case 1:
for (; n ; n--, dst++, src++) {
*(uint8_t *)dst = *(uint8_t *)src;
}
then the compiler is quite likely to "optimize" the loop back to memcpy.
It's also self-documenting what we're intending with the store.
I guess it's also worth asking if this copy is also used for copying *from* device memory.
The commit that added memmove (4a73aee8814) suggests that dma from the device uses these
paths. In which case you'll either want a separate function for that, or both source and
destination must be aligned.
Another unrelated question: why 'int' value is returned from ldub_p()
and ld{uw, l}_he_p() in bswap.h? They would return 'uint{8, 16, 32}_t'
values?
A bad choice 20 years ago, and the need to audit all uses in order to change it
now.
Newer functions use uintN_t as you suggest.
r~
