This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 4/4] - Replace uses of old get_range_strlen with the new one.
- From: Jeff Law <law at redhat dot com>
- To: Martin Sebor <msebor at gmail dot com>, Gcc Patch List <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 10 Oct 2018 16:44:23 -0600
- Subject: Re: [PATCH 4/4] - Replace uses of old get_range_strlen with the new one.
- References: <6ea1f4c0-c5b2-1021-71a8-4316798038f8@gmail.com>
On 10/2/18 10:37 AM, Martin Sebor wrote:
> [4/4] - Replace uses of old get_range_strlen with the new one.
>
> This change switches the remaining get_range_strlen() callers
> to use the new overload of the function that takes a strlen_data_t
> argument. There are no functional changes here.
>
> gcc-99999-4.diff
>
> [4/4] - Replace uses of old get_range_strlen with the new one.
>
> gcc/ChangeLog:
>
> * builtins.c (check_access): Use new get_range_strlen.
> (check_strncat_sizes): Ditto.
> (expand_builtin_strncat): Ditto.
> * calls.c (maybe_warn_nonstring_arg): Ditto.
> * gimple-fold.h (get_range_strlen): Remove unused overload.
> * gimple-fold.c (get_range_strlen): Ditto.
> (gimple_fold_builtin_strlen): Use new get_range_strlen.
>
> diff --git a/gcc/builtins.c b/gcc/builtins.c
> index 3e31af4..daa520b 100644
> --- a/gcc/builtins.c
> +++ b/gcc/builtins.c
> @@ -3235,8 +3235,10 @@ check_access (tree exp, tree, tree, tree dstwrite,
> the upper bound given by MAXREAD add one to it for
> the terminating nul. Otherwise, set it to one for
> the same reason, or to MAXREAD as appropriate. */
> - get_range_strlen (srcstr, range, /* eltsize = */ 1,
> - /* strict = */ false );
> + strlen_data_t lendata (/* eltsize = */ 1);
> + get_range_strlen (srcstr, &lendata);
> + range[0] = lendata.minlen;
> + range[1] = lendata.maxsize;
> if (range[0] && (!maxread || TREE_CODE (maxread) == INTEGER_CST))
Glad to see this cleaned up a little. For whatever reason I find those
/* parm = */ value arguments make quick parsing of the code insanely
painful -- particularly when there's more than one of them. Getting
down to just one helps a lot.
I don't see anything terribly concerning. Obviously we may need
adjustments due to changes in earlier patches, but those would seem trivial.
jeff