All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jerry Van Baren <gerald.vanbaren@ge.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] use of C99
Date: Wed, 08 Apr 2009 15:46:37 -0400	[thread overview]
Message-ID: <49DCFF1D.6080006@ge.com> (raw)
In-Reply-To: <20090408192832.8D48F8560EFB@gemini.denx.de>

Hi Wolfgang,

Wolfgang Denk wrote:
> Dear Kumar Gala,
> 
> In message <4A0B9AAA-4714-4C27-84A7-22FCE4D91DDA@freescale.com> you wrote:
>> I was wondering if there was any reason we avoid C99 features in u- 
>> boot source.
>>
>> Specifically the ability to declare variables in the middle of  
>> functions.
> 
> One reason is that I consider such code extremely ugly and hard to
> read and understand.

ACK.  I don't expect to see variables spring into life in the middle of 
nowhere.

>> There are a slew of places that we have something like:
> ...
>> #ifdef CONFIG_COOL_FEATURE
>> 	u32 myvarrocks = foo * bar * bar;
>>
>> 	gd->neato = myvarrocks
>> #endif
> 
> It would be even better to avoid such #ifdef's, or at least the need
> for such special local variables.

Sometimes (often?) that is impossible.

> Best regards,
> 
> Wolfgang Denk

If I'm not confused, I've seen block-local u-boot variables, has the 
advantages of being more distinctive and limits the lifetime of the 
variable.

#ifdef CONFIG_COOL_FEATURE
	{
		u32 myvarrocks = foo * bar * bar;

		gd->neato = myvarrocks
	}
#endif

Is this an acceptable compromise?

Best regards,
gvb

  reply	other threads:[~2009-04-08 19:46 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-08 18:51 [U-Boot] use of C99 Kumar Gala
2009-04-08 19:28 ` Wolfgang Denk
2009-04-08 19:46   ` Jerry Van Baren [this message]
2009-04-08 20:25     ` Timur Tabi
2009-04-08 20:46       ` Premi, Sanjeev
2009-04-08 20:57         ` Timur Tabi
2009-04-08 21:26           ` Premi, Sanjeev
2009-04-08 21:34             ` Timur Tabi
2009-04-08 21:03         ` Ben Warren
2009-04-08 21:23           ` Premi, Sanjeev
2009-04-08 20:52       ` Scott Wood
2009-04-08 21:01         ` Timur Tabi
2009-04-08 22:26           ` Scott Wood
2009-04-08 21:34       ` Wolfgang Denk
2009-04-08 21:38         ` Timur Tabi
2009-04-08 22:39           ` Graeme Russ
2009-04-08 22:45             ` Timur Tabi
2009-04-08 22:59               ` Wolfgang Denk
2009-04-08 23:09                 ` Scott Wood
2009-04-08 22:28         ` Scott Wood
2009-04-08 21:27     ` Wolfgang Denk
2009-04-08 23:22 ` Larry Johnson
2009-04-08 23:40   ` Scott Wood
2009-04-09  4:27 ` Kumar Gala
2009-04-09 11:38   ` Jerry Van Baren
  -- strict thread matches above, loose matches on Subject: below --
2009-04-09  1:53 Pink Boy
2009-04-09  2:12 ` Jerry Van Baren
2009-04-09  5:50 ` Wolfgang Denk
2009-04-09 13:27   ` Larry Johnson

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=49DCFF1D.6080006@ge.com \
    --to=gerald.vanbaren@ge.com \
    --cc=u-boot@lists.denx.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.