This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: nonstrings in Glibc
On 11/20/2017 10:59 AM, Paul Eggert wrote:
On 11/20/2017 08:54 AM, Martin Sebor wrote:
I've been looking at other uses of strncpy in Glibc to see if there
are other arrays that would benefit from the attribute. I'm not
sufficiently familiar with Glibc data structures so it's a very
slow going. Could someone help suggests data structures with
array members that might be candidates?
If GCC is not warning about uses of the array, what would be the benefit
of marking it with __attribute__ ((nonstring))?
Is this because you're thinking of changing GCC so that it warns about
strlen(x) where x is marked with __attribute__ ((nonstring))? If so, how
would that benefit the typical case? Many char arrays start off being
nonstrings, and are later turned into strings by storing '\0' somewhere.
Although it's not OK to call strlen on these arrays at first, it's fine
to do so later. How would a static attribute capture this typical
situation?
The expectation is that users will use strnlen and other "bounded"
functions with arrays declared non-string rather than strlen et al.
The checker runs late in GCC, after all optimizing transformations,
so provably safe uses of such arrays with unbounded functions are
not diagnosed.
For example:
char a[4] __attribute__ ((nonstring));
int f (void)
{
__builtin_strcpy (a, "123");
return __builtin_strlen (a); // safe, no warning
}
int g (void)
{
__builtin_strncpy (a, "1234", sizeof a);
return __builtin_strlen (a); // not safe, warning
}
a.c: In function ‘g’:
a.c:14:10: warning: ‘__builtin_strlen’ argument 1 declared attribute
‘nonstring’ [-Wstringop-overflow=]
return __builtin_strlen (a); // not safe, warning
^~~~~~~~~~~~~~~~~~~~
a.c:1:6: note: argument ‘a’ declared here
char a[4] __attribute__ ((nonstring));
^
The typical situation is distinct from the strncpy case where
__attribute__ ((nonstring)) applies throught the array's lifetime.
Although I can see that the strlen warning would be useful when code
mistakenly applies strlen to strncpy-like arrays, these arrays are quite
rare in glibc and you should be able to find them all by looking at uses
of strncpy and strncat.
Right, that's goal. I have been looking at strncpy uses but not
really finding any opportunities to annotate character arrays (or
pointers) nonstring beyond those that have already been marked.
I'll keep looking.
Martin