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: