[PATCH] [sim,rx] Silence warning that turns into a build error

[PATCH] [sim,rx] Silence warning that turns into a build error

[Luis Machado]

On a 32-bit build, I ran into the following:

sim/rx/fpu.c:789:6: error: ‘*((void *)&a+8)’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
rv = fp_implode (&a);

To silence this, just initialize the struct with 0's.

sim/rx/ChangeLog:

YYYY-MM-DD  Luis Machado  <luis.machado@linaro.org>

	* fpu.c (rxfp_itof): Initialize structure.
---
 sim/rx/fpu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sim/rx/fpu.c b/sim/rx/fpu.c
index f9e9007192a..9c789e8518c 100644
--- a/sim/rx/fpu.c
+++ b/sim/rx/fpu.c
@@ -732,7 +732,7 @@ rxfp_itof (long fa, int round_mode)
   int sign = 0;
   unsigned int frac_bits;
   volatile unsigned int whole_bits;
-  FP_Parts a;
+  FP_Parts a = {0, 0, 0, 0, 0};
 
   if (fa == 0)
     return PLUS_ZERO;
-- 
2.25.1

Re: [PATCH] [sim,rx] Silence warning that turns into a build error

[Mike Frysinger]

On 08 Apr 2021 16:51, Luis Machado via Gdb-patches wrote:
> +  FP_Parts a = {0, 0, 0, 0, 0};

wouldn't it be simpler & equiv:
	FP_Parts a = {};
-mike

Re: [PATCH] [sim,rx] Silence warning that turns into a build error

[Luis Machado]

On 4/8/21 5:16 PM, Mike Frysinger wrote:
> On 08 Apr 2021 16:51, Luis Machado via Gdb-patches wrote:
>> +  FP_Parts a = {0, 0, 0, 0, 0};
> 
> wouldn't it be simpler & equiv:
> 	FP_Parts a = {};
> -mike
> 

I find that it works, but I'm unsure if it is a standard way of doing it.

The C reference says:

"When initializing an object of struct or union type, the initializer 
must be a non-empty, brace-enclosed, comma-separated list of 
initializers for the members."

So I went with the most obvious, as opposed to going shorter and more 
opaque.

Re: [PATCH] [sim,rx] Silence warning that turns into a build error

[Luis Machado]

On 4/8/21 5:23 PM, Luis Machado wrote:
> On 4/8/21 5:16 PM, Mike Frysinger wrote:
>> On 08 Apr 2021 16:51, Luis Machado via Gdb-patches wrote:
>>> +  FP_Parts a = {0, 0, 0, 0, 0};
>>
>> wouldn't it be simpler & equiv:
>>     FP_Parts a = {};
>> -mike
>>
> 
> I find that it works, but I'm unsure if it is a standard way of doing it.
> 
> The C reference says:
> 
> "When initializing an object of struct or union type, the initializer 
> must be a non-empty, brace-enclosed, comma-separated list of 
> initializers for the members."
> 
> So I went with the most obvious, as opposed to going shorter and more 
> opaque.

It may be the case that sim/ also builds with C++, like GDB. And {} 
would work for that then.

Re: [PATCH] [sim,rx] Silence warning that turns into a build error

[Mike Frysinger]

On 08 Apr 2021 17:23, Luis Machado via Gdb-patches wrote:
> On 4/8/21 5:16 PM, Mike Frysinger wrote:
> > On 08 Apr 2021 16:51, Luis Machado via Gdb-patches wrote:
> >> +  FP_Parts a = {0, 0, 0, 0, 0};
> > 
> > wouldn't it be simpler & equiv:
> > 	FP_Parts a = {};
> 
> I find that it works, but I'm unsure if it is a standard way of doing it.
> 
> The C reference says:
> 
> "When initializing an object of struct or union type, the initializer 
> must be a non-empty, brace-enclosed, comma-separated list of 
> initializers for the members."
> 
> So I went with the most obvious, as opposed to going shorter and more 
> opaque.

my concern is more about having to tweak this whenever fields are added
or removed.

i couldn't remember if the ={} syntax was a C++ extension, or in C11.
if it's a C++ extension, i *think* ={0} will work even in C11.
-mike

Re: [PATCH] [sim,rx] Silence warning that turns into a build error

[Luis Machado]

On 4/8/21 5:57 PM, Mike Frysinger wrote:
> On 08 Apr 2021 17:23, Luis Machado via Gdb-patches wrote:
>> On 4/8/21 5:16 PM, Mike Frysinger wrote:
>>> On 08 Apr 2021 16:51, Luis Machado via Gdb-patches wrote:
>>>> +  FP_Parts a = {0, 0, 0, 0, 0};
>>>
>>> wouldn't it be simpler & equiv:
>>> 	FP_Parts a = {};
>>
>> I find that it works, but I'm unsure if it is a standard way of doing it.
>>
>> The C reference says:
>>
>> "When initializing an object of struct or union type, the initializer
>> must be a non-empty, brace-enclosed, comma-separated list of
>> initializers for the members."
>>
>> So I went with the most obvious, as opposed to going shorter and more
>> opaque.
> 
> my concern is more about having to tweak this whenever fields are added
> or removed.
> 
> i couldn't remember if the ={} syntax was a C++ extension, or in C11.
> if it's a C++ extension, i *think* ={0} will work even in C11.
> -mike
> 

I think it is a C++ thing. I pushed it with the {0} initializer now.