[PATCH] Simplify strncat.

[Joseph Myers]

On Tue, 16 Dec 2014, David Miller wrote:

> The fact that we are talking about complete rewrites for what should
> be a one line warning fix shows that we enabled -Werror prematurely.

No, it simply shows people getting side-tracked and confusing the 
questions of how to fix the build for an existing warning and how to clean 
up the issue it shows up.  The variety of different configurations in 
which people build glibc fundamentally requires the process of fixing 
warnings to be done in parallel by people seeing those warnings (even 
restricted to x86_64 with GCC 4.9, some people are reporting different 
warnings I don't see in such a configuration, so testing all combinations 
of architectures and compiler versions would not cover the warning space).  
The process of fixing warnings started while the -Werror policy was under 
discussion (there was plenty of opportunity for people to fix warnings 
they saw in advance of -Werror being enabled - if they didn't take that 
opportunity, announcing "-Werror will be enabled at X time in the future" 
would hardly have resulted in much more fixing).

My position remains as in 
<https://sourceware.org/ml/libc-alpha/2014-11/msg00693.html>:

  I think we should be perfectly willing to file a bug in Bugzilla and then 
  add a suppression referencing the bug, if there's something tricky about 
  determining if there's a real glibc bug there or a better way to address 
  the warning - that means the build stays working on more platforms (in the 
  presence of -Werror).  I see no reason why we should assume a possible 
  problem in existing code shown up by a warning (from new GCC or on another 
  architecture) is more serious than other bugs.  -Werror is first about 
  stopping new issues getting in accidentally, rather than forcing certain 
  existing issues (those that cause warnings) to be higher priority than 
  other existing issues.

(If the warning that it's hard to work out the correct fix for arises from 
a recent change to glibc, we should be rather more willing to revert that 
change until the fix has been worked out, although that's not necessarily 
the right thing to do in all cases.)

-- 
Joseph S. Myers
joseph@codesourcery.com