Re: PING [PATCH] warn for strlen of arrays with missing nul (PR 86552)

[Bernd Edlinger <bernd.edlinger@hotmail.de>]

Hi,

>@@ -621,6 +674,12 @@ c_strlen (tree src, int only_value)
> 	maxelts = maxelts / eltsize - 1;
>       }
> 
>+  /* Unless the caller is prepared to handle it by passing in a non-null
>+     ARR, fail if the terminating nul doesn't fit in the array the string
>+     is stored in (as in const char a[3] = "123";  */
>+  if (!arr && maxelts < strelts)
>+    return NULL_TREE;
>+

this is c_strlen, how is the caller ever supposed to handle non-zero terminated strings???
especially if you do this above?

>+c_strlen (tree src, int only_value, tree *arr /* = NULL */)
> {
>   STRIP_NOPS (src);
>+
>+  /* Used to detect non-nul-terminated strings in subexpressions
>+     of a conditional expression.  When ARR is null, point it at
>+     one of the elements for simplicity.  */
>+  tree arrs[] = { NULL_TREE, NULL_TREE };
>+  if (!arr)
>+    arr = arrs;

>@@ -11427,7 +11478,9 @@ string_constant (tree arg, tree *ptr_offset)
>   unsigned HOST_WIDE_INT length = TREE_STRING_LENGTH (init);
>   length = string_length (TREE_STRING_POINTER (init), charsize,
> 			  length / charsize);
>-  if (compare_tree_int (array_size, length + 1) < 0)
>+  if (nulterm)
>+    *nulterm = array_elts > length;
>+  else if (array_elts <= length)
>     return NULL_TREE;

I don't understand why you can't use
compare_tree_int (TYPE_SIZE_UNIT (TREE_TYPE (init)), TREE_STRING_LENGTH (init))
instead of this convoluted code above ???

Sorry, this patch does not look like it is ready any time soon.


But actually I am totally puzzled by your priorities.
This is what I see right now:

1) We have missing warnings.
2) We have wrong code bugs.
3) We have apparently a specification error on the C Language standard (*)


Why are you prioritizing 1) over 2) thus blocking my attempts to fix a wrong code
issue,and why do you not tackle 3) in your WG14?



(*) which means that GCC is currently removing code from assertions
as I pointed out here: https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01695.html

This happens because GCC follows the language standards literally right now.

I would say too literally, and it proves that the language standard's logic is
flawed IMHO.

Thanks
Bernd.