From: Harsh Prateek Bora <harshpb@linux.ibm.com>
To: "Cédric Le Goater" <clg@kaod.org>,
"Markus Armbruster" <armbru@redhat.com>,
"Harsh Prateek Bora" <harsh.prateek.bora@gmail.com>
Cc: qemu-ppc@nongnu.org, qemu-devel@nongnu.org,
Daniel Henrique Barboza <danielhb413@gmail.com>,
David Gibson <david@gibson.dropbear.id.au>,
Nicholas Piggin <npiggin@gmail.com>
Subject: Re: [PATCH 8/8] spapr/drc: Clean up local variable shadowing in prop_get_fdt()
Date: Fri, 29 Sep 2023 11:48:38 +0530 [thread overview]
Message-ID: <1c8225b4-75ba-eba1-be8e-d031a911088e@linux.ibm.com> (raw)
In-Reply-To: <b78b73c8-b45d-f4b3-b1e8-47171e9d4446@kaod.org>
On 9/29/23 11:37, Cédric Le Goater wrote:
> On 9/29/23 07:39, Markus Armbruster wrote:
>> Harsh Prateek Bora <harsh.prateek.bora@gmail.com> writes:
>>
>>> On Tue, 19 Sept, 2023, 5:39 pm Cédric Le Goater, <clg@kaod.org> wrote:
>>>
>>>> On 9/19/23 10:48, Harsh Prateek Bora wrote:
>>>>>
>>>>>
>>>>> On 9/18/23 20:28, Cédric Le Goater wrote:
>>>>>> Rename 'name' variable to avoid this warning :
>>>>>>
>>>>>> ../hw/ppc/spapr_drc.c: In function ‘prop_get_fdt’:
>>>>>> ../hw/ppc/spapr_drc.c:344:21: warning: declaration of ‘name’
>>>>>> shadows
>>>> a parameter [-Wshadow=compatible-local]
>>>>>> 344 | const char *name = NULL;
>>>>>> | ^~~~
>>>>>> ../hw/ppc/spapr_drc.c:325:63: note: shadowed declaration is here
>>>>>> 325 | static void prop_get_fdt(Object *obj, Visitor *v,
>>>>>> const char
>>>> *name,
>>>>>> |
>>>> ~~~~~~~~~~~~^~~~
>>>>>>
>>>>>> Signed-off-by: Cédric Le Goater <clg@kaod.org>
>>>>>> ---
>>>>>> hw/ppc/spapr_drc.c | 10 +++++-----
>>>>>> 1 file changed, 5 insertions(+), 5 deletions(-)
>>>>>>
>>>>>> diff --git a/hw/ppc/spapr_drc.c b/hw/ppc/spapr_drc.c
>>>>>> index 843e318312d3..2b99d3b4b1a6 100644
>>>>>> --- a/hw/ppc/spapr_drc.c
>>>>>> +++ b/hw/ppc/spapr_drc.c
>>>>>> @@ -341,7 +341,7 @@ static void prop_get_fdt(Object *obj, Visitor *v,
>>>> const char *name,
>>>>>> fdt_depth = 0;
>>>>>> do {
>>>>>> - const char *name = NULL;
>>>>>> + const char *dt_name = NULL;
>>>>>
>>>>> I guess you wanted to use the input arg "name" here without
>>>> re-declaration.
>>>>
>>>> I don't understand. I don't want to use the input arg "name" here.
>>>> It seems useless in this case.
>>>>
>>>
>>> Yeh, I realize now. This patch can actually remove the unused arg
>>> "name" as
>>> well?
>>
>> Cédric?
>>
>> Lose ends like this one make me reluctant to queue a series, even when
>> they look minor to me.
>
> Unfortunately, we can not remove the unused arg "name" from the prototype.
> The routine is a ObjectPropertyAccessor argument of object_property_add().
>
Hmm, I see ..
Reviewed-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
> Thanks,
>
> C.
>
>
>>
>>>> C.
>>>>
>>>>> I do not see "name" being used elsewhere in this routine.
>>>>>
>>>>> regards,
>>>>> Harsh
>>>>>> const struct fdt_property *prop = NULL;
>>>>>> int prop_len = 0, name_len = 0;
>>>>>> uint32_t tag;
>>>>>> @@ -351,8 +351,8 @@ static void prop_get_fdt(Object *obj, Visitor *v,
>>>> const char *name,
>>>>>> switch (tag) {
>>>>>> case FDT_BEGIN_NODE:
>>>>>> fdt_depth++;
>>>>>> - name = fdt_get_name(fdt, fdt_offset, &name_len);
>>>>>> - if (!visit_start_struct(v, name, NULL, 0, errp)) {
>>>>>> + dt_name = fdt_get_name(fdt, fdt_offset, &name_len);
>>>>>> + if (!visit_start_struct(v, dt_name, NULL, 0, errp)) {
>>>>>> return;
>>>>>> }
>>>>>> break;
>>>>>> @@ -369,8 +369,8 @@ static void prop_get_fdt(Object *obj, Visitor *v,
>>>> const char *name,
>>>>>> case FDT_PROP: {
>>>>>> int i;
>>>>>> prop = fdt_get_property_by_offset(fdt, fdt_offset,
>>>> &prop_len);
>>>>>> - name = fdt_string(fdt, fdt32_to_cpu(prop->nameoff));
>>>>>> - if (!visit_start_list(v, name, NULL, 0, errp)) {
>>>>>> + dt_name = fdt_string(fdt, fdt32_to_cpu(prop->nameoff));
>>>>>> + if (!visit_start_list(v, dt_name, NULL, 0, errp)) {
>>>>>> return;
>>>>>> }
>>>>>> for (i = 0; i < prop_len; i++) {
>>
>
next prev parent reply other threads:[~2023-09-29 6:19 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-18 14:58 [PATCH 0/8] ppc: Clean up local variable shadowing Cédric Le Goater
2023-09-18 14:58 ` [PATCH 1/8] hw/ppc: Clean up local variable shadowing in _FDT helper routine Cédric Le Goater
2023-09-19 6:53 ` Harsh Prateek Bora
2023-09-18 14:58 ` [PATCH 2/8] pnv/psi: Clean up local variable shadowing Cédric Le Goater
2023-09-19 6:57 ` Harsh Prateek Bora
2023-09-19 9:03 ` Cédric Le Goater
2023-09-29 5:30 ` Markus Armbruster
2023-09-29 6:13 ` Cédric Le Goater
2023-09-18 14:58 ` [PATCH 3/8] spapr: Clean up local variable shadowing in spapr_dt_cpus() Cédric Le Goater
2023-09-19 7:28 ` Harsh Prateek Bora
2023-09-19 11:05 ` Cédric Le Goater
2023-09-19 13:04 ` Harsh Prateek Bora
2023-09-19 14:59 ` Harsh Prateek Bora
2023-09-19 15:05 ` Cédric Le Goater
2023-09-18 14:58 ` [PATCH 4/8] spapr: Clean up local variable shadowing in spapr_init_cpus() Cédric Le Goater
2023-09-19 7:30 ` Harsh Prateek Bora
2023-09-18 14:58 ` [PATCH 5/8] spapr: Clean up local variable shadowing in spapr_get_fw_dev_path() Cédric Le Goater
2023-09-18 15:29 ` Philippe Mathieu-Daudé
2023-09-19 8:23 ` Harsh Prateek Bora
2023-09-19 11:54 ` Cédric Le Goater
2023-09-18 14:58 ` [PATCH 6/8] spapr/drc: Clean up local variable shadowing in rtas_ibm_configure_connector() Cédric Le Goater
2023-09-19 8:29 ` Harsh Prateek Bora
2023-09-19 12:02 ` Cédric Le Goater
2023-09-19 13:01 ` Harsh Prateek Bora
2023-09-29 5:34 ` Markus Armbruster
2023-09-29 5:43 ` Harsh Prateek Bora
2023-09-18 14:58 ` [PATCH 7/8] spapr/pci: Clean up local variable shadowing in spapr_phb_realize() Cédric Le Goater
2023-09-19 8:38 ` Harsh Prateek Bora
2023-09-19 12:04 ` Cédric Le Goater
2023-09-18 14:58 ` [PATCH 8/8] spapr/drc: Clean up local variable shadowing in prop_get_fdt() Cédric Le Goater
2023-09-18 15:30 ` Philippe Mathieu-Daudé
2023-09-19 8:48 ` Harsh Prateek Bora
2023-09-19 12:07 ` Cédric Le Goater
2023-09-19 12:55 ` Harsh Prateek Bora
2023-09-29 5:39 ` Markus Armbruster
2023-09-29 6:07 ` Cédric Le Goater
2023-09-29 6:18 ` Harsh Prateek Bora [this message]
2023-10-04 10:26 ` [PATCH 0/8] ppc: Clean up local variable shadowing Markus Armbruster
2023-10-04 11:56 ` Cédric Le Goater
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1c8225b4-75ba-eba1-be8e-d031a911088e@linux.ibm.com \
--to=harshpb@linux.ibm.com \
--cc=armbru@redhat.com \
--cc=clg@kaod.org \
--cc=danielhb413@gmail.com \
--cc=david@gibson.dropbear.id.au \
--cc=harsh.prateek.bora@gmail.com \
--cc=npiggin@gmail.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).