[PATCH v3] ata: libata-core: initialize native_sectors in ata_hpa_resize()

[PATCH v3] ata: libata-core: initialize native_sectors in ata_hpa_resize()

[Simon Que]

Eliminates a compiler warning about uninitialized variable.
"warning: 'native_sectors' may be used uninitialized in this function"

Signed-off-by: Simon Que <sque@chromium.org>
---
 drivers/ata/libata-core.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index d2b18ea..b185db1 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -1324,7 +1324,7 @@ static int ata_hpa_resize(struct ata_device *dev)
 	int print_info = ehc->i.flags & ATA_EHI_PRINTINFO;
 	bool unlock_hpa = ata_ignore_hpa || dev->flags & ATA_DFLAG_UNLOCK_HPA;
 	u64 sectors = ata_id_n_sectors(dev->id);
-	u64 native_sectors;
+	u64 native_sectors = 0;
 	int rc;
 
 	/* do we need to do it? */
-- 
1.7.8.6

Re: [PATCH v3] ata: libata-core: initialize native_sectors in ata_hpa_resize()

[Sergei Shtylyov]

Hello.

On 24-01-2013 23:57, Simon Que wrote:

> Eliminates a compiler warning about uninitialized variable.
> "warning: 'native_sectors' may be used uninitialized in this function"

> Signed-off-by: Simon Que <sque@chromium.org>
> ---
>   drivers/ata/libata-core.c |    2 +-
>   1 files changed, 1 insertions(+), 1 deletions(-)

> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
> index d2b18ea..b185db1 100644
> --- a/drivers/ata/libata-core.c
> +++ b/drivers/ata/libata-core.c
> @@ -1324,7 +1324,7 @@ static int ata_hpa_resize(struct ata_device *dev)
>   	int print_info = ehc->i.flags & ATA_EHI_PRINTINFO;
>   	bool unlock_hpa = ata_ignore_hpa || dev->flags & ATA_DFLAG_UNLOCK_HPA;
>   	u64 sectors = ata_id_n_sectors(dev->id);
> -	u64 native_sectors;
> +	u64 native_sectors = 0;

    Isn't it wiser to set it to 'sectors'? And frankly speaking I don't see 
how this variable may indeed be used unitialized. What version of gcc are you 
using?

MBR, Sergei

Re: [PATCH v3] ata: libata-core: initialize native_sectors in ata_hpa_resize()

[Simon Que]

I'm using a ChromeOS / ChromiumOS gcc.

Technically it won't be used uninitialized since there's a check for
the return value.  But this isn't always obvious to the compiler --
it'd have to be smart enough to look at ata_read_native_max_address()
to see that if '*max_sectors' is not set, then there is a nonzero
return value, which would cause ata_hpa_resize() to return early.

This patch is really meant to satisfy the compiler, rather than to
catch some corner case where 'native_sectors' gets used uninitialized.
 Setting it to 0 makes more sense because its "true initialization" is
in a later call.

On Fri, Jan 25, 2013 at 3:21 AM, Sergei Shtylyov <sshtylyov@mvista.com> wrote:
> Hello.
>
>
> On 24-01-2013 23:57, Simon Que wrote:
>
>> Eliminates a compiler warning about uninitialized variable.
>> "warning: 'native_sectors' may be used uninitialized in this function"
>
>
>> Signed-off-by: Simon Que <sque@chromium.org>
>> ---
>>   drivers/ata/libata-core.c |    2 +-
>>   1 files changed, 1 insertions(+), 1 deletions(-)
>
>
>> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
>> index d2b18ea..b185db1 100644
>> --- a/drivers/ata/libata-core.c
>> +++ b/drivers/ata/libata-core.c
>> @@ -1324,7 +1324,7 @@ static int ata_hpa_resize(struct ata_device *dev)
>>         int print_info = ehc->i.flags & ATA_EHI_PRINTINFO;
>>         bool unlock_hpa = ata_ignore_hpa || dev->flags &
>> ATA_DFLAG_UNLOCK_HPA;
>>         u64 sectors = ata_id_n_sectors(dev->id);
>> -       u64 native_sectors;
>> +       u64 native_sectors = 0;
>
>
>    Isn't it wiser to set it to 'sectors'? And frankly speaking I don't see
> how this variable may indeed be used unitialized. What version of gcc are
> you using?
>
> MBR, Sergei
>

Re: [PATCH v3] ata: libata-core: initialize native_sectors in ata_hpa_resize()

[Simon Que]

More specifically... I have gcc 4.7.1.

On Fri, Jan 25, 2013 at 3:31 PM, Simon Que <sque@chromium.org> wrote:
> I'm using a ChromeOS / ChromiumOS gcc.
>
> Technically it won't be used uninitialized since there's a check for
> the return value.  But this isn't always obvious to the compiler --
> it'd have to be smart enough to look at ata_read_native_max_address()
> to see that if '*max_sectors' is not set, then there is a nonzero
> return value, which would cause ata_hpa_resize() to return early.
>
> This patch is really meant to satisfy the compiler, rather than to
> catch some corner case where 'native_sectors' gets used uninitialized.
>  Setting it to 0 makes more sense because its "true initialization" is
> in a later call.
>
> On Fri, Jan 25, 2013 at 3:21 AM, Sergei Shtylyov <sshtylyov@mvista.com> wrote:
>> Hello.
>>
>>
>> On 24-01-2013 23:57, Simon Que wrote:
>>
>>> Eliminates a compiler warning about uninitialized variable.
>>> "warning: 'native_sectors' may be used uninitialized in this function"
>>
>>
>>> Signed-off-by: Simon Que <sque@chromium.org>
>>> ---
>>>   drivers/ata/libata-core.c |    2 +-
>>>   1 files changed, 1 insertions(+), 1 deletions(-)
>>
>>
>>> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
>>> index d2b18ea..b185db1 100644
>>> --- a/drivers/ata/libata-core.c
>>> +++ b/drivers/ata/libata-core.c
>>> @@ -1324,7 +1324,7 @@ static int ata_hpa_resize(struct ata_device *dev)
>>>         int print_info = ehc->i.flags & ATA_EHI_PRINTINFO;
>>>         bool unlock_hpa = ata_ignore_hpa || dev->flags &
>>> ATA_DFLAG_UNLOCK_HPA;
>>>         u64 sectors = ata_id_n_sectors(dev->id);
>>> -       u64 native_sectors;
>>> +       u64 native_sectors = 0;
>>
>>
>>    Isn't it wiser to set it to 'sectors'? And frankly speaking I don't see
>> how this variable may indeed be used unitialized. What version of gcc are
>> you using?
>>
>> MBR, Sergei
>>