[Dropping tz@iana.org as this email isn't relevant to tzdb.]
Martin Sebor wrote:
I tried to make only minimal changes to suppress
the new warning to avoid excessive churn.
As the main goal here is to find bugs not to pacify GCC, it's helpful to
take these diagnostics as an opportunity to look more carefully at the
strncpy calls. I just now looked at the other two data structures
affected by the patch, and found some issues.
First, the patch to sysdeps/gnu/bits/utmp.h seems reasonable, as the
members ut_user etc. have used strncpy format since the 1970s and people
who deal with this format are used to it. However, this format does not
appear to be documented in the manual. I suggest accompanying it with a
patch to the part of manual/users.texi that talks about ut_user etc., so
that the __NONSTRING issue is documented there.
Second, the patch to sysdeps/gnu/net/if.h is dubious. Its goal appears
to be to pacify calls like the first call to strncpy in
sysdeps/unix/sysv/linux/if_index.c. But that first call appears to be a
bug in glibc, since the underlying Linux system call expects a
null-terminated string. My guess is that
this particular data structure should indeed be a null-terminated
string, and should not be marked with __NONSTRING, and that we should
instead change the glibc code to not use strncpy here. I suppose the
code should report an error instead of creating a non-null-terminated
array, and that it need not initialize the rest of the array to zeros.