Thanks for the explanation, Martin! On Thu, Dec 12, 2019 at 05:20:43PM -0700, Martin Sebor wrote: > I don't see it with > fresh trunk, either natively or with an m68k-unknown-elf cross, so > I can't really say why GCC 9 thinks the two pointers are equal. Thus there's a chance that the warning will go away with one of the next GCC releases? > You > can tell by looking at the optimization dumps (use -ftree-dump-all > and grep the output for strncpy with a zero argument). Hmmm. No -ftree-dump-XXX options here. > What I can say is that strncpy isn't really meant to be used this > way: to copy exactly as many bytes as the third argument says. > That's what memcpy is for. I tend to use memXXX() family of functions when I am dealing with binary data. Here, I am dealing with zero terminated strings. Thus, the strXXX() family of functions should be used. IMHO, of course! > The warning was added because strncpy > is frequently misused and a common source of bugs. I am not sure I understand which kind of misuse you are talking about. I see there's a pitfall with strncpy() failing to add the terminating NUL charachter. But this terminating NUL is added explicitly in this case. > The warning > tries to avoid triggering for the safe uses when it can detect > they are safe, but it's imperfect and prone to false alarms. False alarms teach people to ignore warnings. > To avoid it I would suggest using memcpy instead. It will likely > also be faster. Alternatively, you can try calling the function > only when the difference is non-zero. I agree that memcpy() could do the job and would probably be even faster. But this is about semantics. This piece of code is dealing with zero terminated strings. -- Josef Wolf jw@xxxxxxxxxxxxx
