On Fri, May 26, 2023 at 08:34:20AM -0700, Wayne Davison wrote: > On Tue, May 16, 2023 at 2:03 PM Derek Martin wrote: > > > This appears to be because of a type mismatch between xfer_sum_len > > (declared as [signed] int) and the third arugment to memset, whose > > function prototype is (from the man page): > > > > void *memset(void *s, int c, size_t n); > > > > If that is the case, why does it not complain about file_sum_len, which is > also an int that is passed to memset()? The only difference I see is that > xfer_sum_len's memset() is in match.c while file_sum_len's memset() is in > checksum.c, and the only difference I can see with that is that the int is > local to checksum.c and extern in match.c. Very strange. I'm more inclined > to change them into unsigned short values, as they are quite small integers.
I can't answer that question--I'm no expert on GCC internals and what trips its paranoia checks. I wouldn't be surprised if it was due to a bug in GCC causing the checks to be overzealous--when I googled it appeared that there might have been such a bug. However it's hard to deny that the types are indeed mismatched, or that properly matching them will certainly eliminate the possibility of such problems going forward... As for unsigned short vs. size_t... You can certainly do what you want, but as far as I could tell the variable exists for the purpose of identifying the size in bytes of a thing, for which size_t explicitly exists, and it is only ever used in the context of things that are also size_t, so--regardless of the expected range of values--I don't see that it saves much or serves any useful purpose to avoid just making it size_t. -- Derek Martin Principal System Software Engineer Akamai Technologies demar...@akamai.com -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
