nonstrings in Glibc

[Martin Sebor]

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