[U-Boot] [PATCH 1/2] Move uninitialized_var() macro from ubi_uboot.h to compiler.h

[U-Boot] [PATCH 1/2] Move uninitialized_var() macro from ubi_uboot.h to compiler.h

[Anton Vorontsov]

This is needed so that we could use this macro for non-UBI code.

Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
 include/compiler.h  |    3 +++
 include/ubi_uboot.h |    4 +---
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/include/compiler.h b/include/compiler.h
index 272fd3c..e602cce 100644
--- a/include/compiler.h
+++ b/include/compiler.h
@@ -122,4 +122,7 @@ typedef unsigned int            uintptr_t;
 
 #endif
 
+/* compiler options */
+#define uninitialized_var(x)		x = x
+
 #endif
diff --git a/include/ubi_uboot.h b/include/ubi_uboot.h
index 74312ab..60f6a5f 100644
--- a/include/ubi_uboot.h
+++ b/include/ubi_uboot.h
@@ -15,6 +15,7 @@
 #define __UBOOT_UBI_H
 
 #include <common.h>
+#include <compiler.h>
 #include <malloc.h>
 #include <div64.h>
 #include <linux/crc32.h>
@@ -51,9 +52,6 @@ do {									\
 #undef CONFIG_MTD_UBI_DEBUG_MSG_BLD
 #define CONFIG_MTD_UBI_DEBUG_DISABLE_BGT
 
-/* compiler options */
-#define uninitialized_var(x)		x = x
-
 /* build.c */
 #define get_device(...)
 #define put_device(...)
-- 
1.6.3.3

[U-Boot] [PATCH 1/2] Move uninitialized_var() macro from ubi_uboot.h to compiler.h

[Wolfgang Denk]

Dear Anton Vorontsov,

In message <20090901165803.GA3668@oksana.dev.rtsoft.ru> you wrote:
> This is needed so that we could use this macro for non-UBI code.
> 
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
>  include/compiler.h  |    3 +++
>  include/ubi_uboot.h |    4 +---
>  2 files changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/include/compiler.h b/include/compiler.h
> index 272fd3c..e602cce 100644
> --- a/include/compiler.h
> +++ b/include/compiler.h
> @@ -122,4 +122,7 @@ typedef unsigned int            uintptr_t;
>  
>  #endif
>  
> +/* compiler options */
> +#define uninitialized_var(x)		x = x

Please excuse my ignorance, but where and what for is such a
definition useful?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Faith may be defined briefly as an illogical belief in the  occurence
of the improbable.                                    - H. L. Mencken

[U-Boot] [PATCH 1/2] Move uninitialized_var() macro from ubi_uboot.h to compiler.h

[Anton Vorontsov]

On Tue, Sep 01, 2009 at 08:11:41PM +0200, Wolfgang Denk wrote:
> Dear Anton Vorontsov,
> 
> In message <20090901165803.GA3668@oksana.dev.rtsoft.ru> you wrote:
> > This is needed so that we could use this macro for non-UBI code.
> > 
> > Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> > ---
> >  include/compiler.h  |    3 +++
> >  include/ubi_uboot.h |    4 +---
> >  2 files changed, 4 insertions(+), 3 deletions(-)
> > 
> > diff --git a/include/compiler.h b/include/compiler.h
> > index 272fd3c..e602cce 100644
> > --- a/include/compiler.h
> > +++ b/include/compiler.h
> > @@ -122,4 +122,7 @@ typedef unsigned int            uintptr_t;
> >  
> >  #endif
> >  
> > +/* compiler options */
> > +#define uninitialized_var(x)		x = x
> 
> Please excuse my ignorance, but where and what for is such a
> definition useful?

It's used to avoid GCC warnings, i.e. when GCC isn't smart enough
to see that some variable isn't actually used uninitialized.

~/linux-2.6$ git grep uninitialized_var drivers/ | wc -l
94

We can fix the warnings by assigning some value to a variable
at declaration, but the advantage of 'x = x' trick is that it
doesn't generate any code.

Thanks,

-- 
Anton Vorontsov
email: cbouatmailru at gmail.com
irc://irc.freenode.net/bd2

[U-Boot] [PATCH 1/2] Move uninitialized_var() macro from ubi_uboot.h to compiler.h

[Albin Tonnerre]

On Tue, Sep 01, 2009 at 10:25:18PM +0400, Anton Vorontsov wrote :
> On Tue, Sep 01, 2009 at 08:11:41PM +0200, Wolfgang Denk wrote:
> > Dear Anton Vorontsov,
> > 
> > In message <20090901165803.GA3668@oksana.dev.rtsoft.ru> you wrote:
> > > This is needed so that we could use this macro for non-UBI code.
> > > 
> > > Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> > > ---
> > >  include/compiler.h  |    3 +++
> > >  include/ubi_uboot.h |    4 +---
> > >  2 files changed, 4 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/include/compiler.h b/include/compiler.h
> > > index 272fd3c..e602cce 100644
> > > --- a/include/compiler.h
> > > +++ b/include/compiler.h
> > > @@ -122,4 +122,7 @@ typedef unsigned int            uintptr_t;
> > >  
> > >  #endif
> > >  
> > > +/* compiler options */
> > > +#define uninitialized_var(x)		x = x
> > 
> > Please excuse my ignorance, but where and what for is such a
> > definition useful?
> 
> It's used to avoid GCC warnings, i.e. when GCC isn't smart enough
> to see that some variable isn't actually used uninitialized.
> 
> ~/linux-2.6$ git grep uninitialized_var drivers/ | wc -l
> 94

You seem to be grepping the linux source tree. The whole U-boot codebase
contains only 10 of them.

> We can fix the warnings by assigning some value to a variable
> at declaration, but the advantage of 'x = x' trick is that it
> doesn't generate any code.

I'm not quite sure that would be noticeable given the number of uses (I don't
have any opinion as to whether we should initialize them properly, though).

Regards,
-- 
Albin Tonnerre, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: Digital signature
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090901/72c28aed/attachment.pgp 

[U-Boot] [PATCH 1/2] Move uninitialized_var() macro from ubi_uboot.h to compiler.h

[Anton Vorontsov]

On Tue, Sep 01, 2009 at 08:52:33PM +0200, Albin Tonnerre wrote:
[...]
> > > > +/* compiler options */
> > > > +#define uninitialized_var(x)		x = x
> > > 
> > > Please excuse my ignorance, but where and what for is such a
> > > definition useful?
> > 
> > It's used to avoid GCC warnings, i.e. when GCC isn't smart enough
> > to see that some variable isn't actually used uninitialized.
> > 
> > ~/linux-2.6$ git grep uninitialized_var drivers/ | wc -l
> > 94
> 
> You seem to be grepping the linux source tree.

Yes, which is a great source of best practices.

Thanks,

-- 
Anton Vorontsov
email: cbouatmailru at gmail.com
irc://irc.freenode.net/bd2

[U-Boot] [PATCH 1/2] Move uninitialized_var() macro from ubi_uboot.h to compiler.h

[Mike Frysinger]

On Tuesday 01 September 2009 15:58:14 Anton Vorontsov wrote:
> On Tue, Sep 01, 2009 at 08:52:33PM +0200, Albin Tonnerre wrote:
> > > > > +/* compiler options */
> > > > > +#define uninitialized_var(x)		x = x
> > > >
> > > > Please excuse my ignorance, but where and what for is such a
> > > > definition useful?
> > >
> > > It's used to avoid GCC warnings, i.e. when GCC isn't smart enough
> > > to see that some variable isn't actually used uninitialized.
> > >
> > > ~/linux-2.6$ git grep uninitialized_var drivers/ | wc -l
> > > 94
> >
> > You seem to be grepping the linux source tree.
>
> Yes, which is a great source of best practices.

except you didnt filter drivers/staging/ thus negating any results you might 
try to use to back up arguments
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090901/9a3d1142/attachment.pgp 

[U-Boot] [PATCH 1/2] Move uninitialized_var() macro from ubi_uboot.h to compiler.h

[Wolfgang Denk]

Dear Anton Vorontsov,

In message <20090901182518.GA17903@oksana.dev.rtsoft.ru> you wrote:
>
> We can fix the warnings by assigning some value to a variable
> at declaration, but the advantage of 'x = x' trick is that it
> doesn't generate any code.

Argh... what a clev^H^H^H^Hdirty trick.

Thanks for the explanation.

However, in this case it seems to make sense to me to explicitly
initialize the return code with zero.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A man either lives life as it happens to him, meets  it  head-on  and
licks it, or he turns his back on it and starts to wither away.
	-- Dr. Boyce, "The Menagerie" ("The Cage"), stardate unknown

[U-Boot] [PATCH v2] fsl: sys_eeprom: Fix 'may be used uninitialized' warning

[Anton Vorontsov]

The warning is bogus, so silence it by initializing the 'ret' variable.

Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---

On Tue, Sep 01, 2009 at 09:27:37PM +0200, Wolfgang Denk wrote:
> Dear Anton Vorontsov,
> 
> In message <20090901182518.GA17903@oksana.dev.rtsoft.ru> you wrote:
> >
> > We can fix the warnings by assigning some value to a variable
> > at declaration, but the advantage of 'x = x' trick is that it
> > doesn't generate any code.
> 
> Argh... what a clev^H^H^H^Hdirty trick.
> 
> Thanks for the explanation.
> 
> However, in this case it seems to make sense to me to explicitly
> initialize the return code with zero.

Well, I don't see any advantages of this, but here it is anyway.

Thanks.

p.s. Timur, since the patch has changed, I couldn't preserve your
     previous Ack.

 board/freescale/common/sys_eeprom.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/board/freescale/common/sys_eeprom.c b/board/freescale/common/sys_eeprom.c
index c0fff68..661015e 100644
--- a/board/freescale/common/sys_eeprom.c
+++ b/board/freescale/common/sys_eeprom.c
@@ -204,7 +204,8 @@ static void update_crc(void)
  */
 static int prog_eeprom(void)
 {
-	int ret, i;
+	int ret = 0; /* shut up gcc */
+	int i;
 	void *p;
 #ifdef CONFIG_SYS_EEPROM_BUS_NUM
 	unsigned int bus;
-- 
1.6.3.3

[U-Boot] [PATCH v2] fsl: sys_eeprom: Fix 'may be used uninitialized' warning

[Timur Tabi]

Anton Vorontsov wrote:

> p.s. Timur, since the patch has changed, I couldn't preserve your
>      previous Ack.

I'm okay with this version, too.


-- 
Timur Tabi
Linux kernel developer at Freescale

[U-Boot] [PATCH v2] fsl: sys_eeprom: Fix 'may be used uninitialized' warning

[Kumar Gala]

On Sep 1, 2009, at 5:17 PM, Anton Vorontsov wrote:

> The warning is bogus, so silence it by initializing the 'ret'  
> variable.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
>
> On Tue, Sep 01, 2009 at 09:27:37PM +0200, Wolfgang Denk wrote:
>> Dear Anton Vorontsov,
>>
>> In message <20090901182518.GA17903@oksana.dev.rtsoft.ru> you wrote:
>>>
>>> We can fix the warnings by assigning some value to a variable
>>> at declaration, but the advantage of 'x = x' trick is that it
>>> doesn't generate any code.
>>
>> Argh... what a clev^H^H^H^Hdirty trick.
>>
>> Thanks for the explanation.
>>
>> However, in this case it seems to make sense to me to explicitly
>> initialize the return code with zero.
>
> Well, I don't see any advantages of this, but here it is anyway.
>
> Thanks.
>
> p.s. Timur, since the patch has changed, I couldn't preserve your
>     previous Ack.
>
> board/freescale/common/sys_eeprom.c |    3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)


applied to 85xx.

- k

[U-Boot] [PATCH 1/2] Move uninitialized_var() macro from ubi_uboot.h to compiler.h

[Wolfgang Denk]

Dear Anton Vorontsov,

In message <20090901165803.GA3668@oksana.dev.rtsoft.ru> you wrote:
> This is needed so that we could use this macro for non-UBI code.
> 
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
>  include/compiler.h  |    3 +++
>  include/ubi_uboot.h |    4 +---
>  2 files changed, 4 insertions(+), 3 deletions(-)

Applied, thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
There are three ways to get something  done:  do  it  yourself,  hire
someone, or forbid your kids to do it.