Re: shadow variables - pg15 edition - Mailing list pgsql-hackers

From Andres Freund
Subject Re: shadow variables - pg15 edition
Date
Msg-id 20221006003920.6xlqaoccxwisza5k@awork3.anarazel.de
Whole thread Raw
In response to Re: shadow variables - pg15 edition  (David Rowley <dgrowleyml@gmail.com>)
Responses Re: shadow variables - pg15 edition
Re: shadow variables - pg15 edition
List pgsql-hackers
Hi,

On 2022-10-06 13:00:41 +1300, David Rowley wrote:
> Here's a patch which (I think) fixes the ones I missed.

Yep, does the trick for me.

I attached a patch to add -Wshadow=compatible-local to our set of warnings.


> diff --git a/contrib/hstore/hstore.h b/contrib/hstore/hstore.h
> index 4713e6ea7a..897af244a4 100644
> --- a/contrib/hstore/hstore.h
> +++ b/contrib/hstore/hstore.h
> @@ -128,15 +128,15 @@ typedef struct
>  /* finalize a newly-constructed hstore */
>  #define HS_FINALIZE(hsp_,count_,buf_,ptr_)                            \
>      do {                                                            \
> -        int buflen = (ptr_) - (buf_);                                \
> +        int _buflen = (ptr_) - (buf_);                                \

Not pretty. Given that HS_FINALIZE already has multiple-eval hazards, perhaps
we could just remove the local?



> --- a/src/interfaces/libpq/fe-secure-gssapi.c
> +++ b/src/interfaces/libpq/fe-secure-gssapi.c
> @@ -135,11 +135,11 @@ pg_GSS_write(PGconn *conn, const void *ptr, size_t len)
>           */
>          if (PqGSSSendLength)
>          {
> -            ssize_t        ret;
> +            ssize_t        retval;

That looks like it could easily lead to confusion further down the
line. Wouldn't the better fix here be to remove the inner variable?


> --- a/src/pl/plpython/plpy_exec.c
> +++ b/src/pl/plpython/plpy_exec.c
> @@ -375,11 +375,11 @@ PLy_exec_trigger(FunctionCallInfo fcinfo, PLyProcedure *proc)
>                  rv = NULL;
>              else if (pg_strcasecmp(srv, "MODIFY") == 0)
>              {
> -                TriggerData *tdata = (TriggerData *) fcinfo->context;
> +                TriggerData *trigdata = (TriggerData *) fcinfo->context;
>  
> -                if (TRIGGER_FIRED_BY_INSERT(tdata->tg_event) ||
> -                    TRIGGER_FIRED_BY_UPDATE(tdata->tg_event))
> -                    rv = PLy_modify_tuple(proc, plargs, tdata, rv);
> +                if (TRIGGER_FIRED_BY_INSERT(trigdata->tg_event) ||
> +                    TRIGGER_FIRED_BY_UPDATE(trigdata->tg_event))
> +                    rv = PLy_modify_tuple(proc, plargs, trigdata, rv);
>                  else
>                      ereport(WARNING,
>                              (errmsg("PL/Python trigger function returned \"MODIFY\" in a DELETE trigger --
ignored")));

This doesn't strike me as a good fix either. Isn't the inner tdata exactly
the same as the outer tdata?

    tdata = (TriggerData *) fcinfo->context;
...
                TriggerData *trigdata = (TriggerData *) fcinfo->context;



> --- a/src/test/modules/test_integerset/test_integerset.c
> +++ b/src/test/modules/test_integerset/test_integerset.c
> @@ -585,26 +585,26 @@ test_huge_distances(void)

This is one of the cases where our insistence on -Wdeclaration-after-statement
really makes this unnecessary ugly... Declaring x at the start of the function
just makes this harder to read.

Anyway, this isn't important code, and your fix seem ok.


Greetings,

Andres Freund

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Add meson.build to version_stamp.pl
Next
From: Andres Freund
Date:
Subject: Re: START_REPLICATION SLOT causing a crash in an assert build