This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PING [PATCH] warn for strlen of arrays with missing nul (PR 86552)
- From: Bernd Edlinger <bernd dot edlinger at hotmail dot de>
- To: Martin Sebor <msebor at gmail dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 30 Jul 2018 21:11:53 +0000
- Subject: Re: PING [PATCH] warn for strlen of arrays with missing nul (PR 86552)
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.