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

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

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

Reply via email to