Wolfgang Denk wrote:
> Dear Pink Boy,
>
> In message <139940.41801...@web31807.mail.mud.yahoo.com> you wrote:
>> Um... my feeling is that if one is going to declare a variable
>> inside a #ifdef then that variable ought to be called something
>> like
>>
>> int indx_CONFIG_COOL_FEATURE
>>
>> and
Kumar Gala wrote:
> I'm glad to see I started this week's flame thread :)
>
> - k
Wolfgang will have to add a new stat to his releases statistics:
originator of the longest threads (top 10, sorted by length). :-P
gvb
___
U-Boot mailing list
U-Boot@li
Dear Pink Boy,
In message <139940.41801...@web31807.mail.mud.yahoo.com> you wrote:
>
> Um... my feeling is that if one is going to declare a variable
> inside a #ifdef then that variable ought to be called something
> like
>
> int indx_CONFIG_COOL_FEATURE
>
> and
>
> u32 indx_CONFIG_HOT_F
I'm glad to see I started this week's flame thread :)
- k
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Pink Boy wrote:
[snip]
> Pops out of hole, looks at shadow, 6 more weeks till we ship...
>
> Um... my feeling is that if one is going to declare a variable
> inside a #ifdef then that variable ought to be called something
> like
>
> int indx_CONFIG_COOL_FEATURE
>
> and
>
> u32 indx_CONFI
Premi, Sanjeev sez,
> I was referring to declaring variable within #ifdefs with
> belief that
> use will be contained.
>
> e.g.
> #ifdef CONFIG_COOL_FEATURE
> int i;
> int* ptr ;
> ...
> ...
> #endif
>
> ...
> ... 2 screenful down; in same function...
> ...
>
> #ifdef CO
Larry Johnson wrote:
> Kumar Gala wrote:
>> I was wondering if there was any reason we avoid C99 features in u-
>> boot source.
>
> Maybe the best reason is that the Linux kernel avoids them,
Linux has a lot more inertia than a smaller project such as u-boot.
> and staying consistent with the
Kumar Gala wrote:
> I was wondering if there was any reason we avoid C99 features in u-
> boot source.
Maybe the best reason is that the Linux kernel avoids them, and staying
consistent with the Linux coding style saves a lot of time and
headaches. IMO, this is worth the occasional clumsiness th
Wolfgang Denk wrote:
> Dear Timur Tabi,
>
> In message <49dd290a.9010...@freescale.com> you wrote:
>> It's like complaining to someone who has a car that you only have a
>> bicycle and you have to commute 20 miles to get to work. The person who
>> has a car is obviously going to tell you that you
Dear Timur Tabi,
In message <49dd290a.9010...@freescale.com> you wrote:
>
> It's like complaining to someone who has a car that you only have a
> bicycle and you have to commute 20 miles to get to work. The person who
> has a car is obviously going to tell you that your life will be easier
> if
Graeme Russ wrote:
> What if _MY_ favourite editor doesn't.
The point I'm trying to make is that I have tools at my disposal that
make certain tasks easier for me, allowing me to alter my coding style
and get the best of both worlds.
> Or what if I don't have access to
> it because I'm looking
On Thu, Apr 9, 2009 at 7:38 AM, Timur Tabi wrote:
> Wolfgang Denk wrote:
>
>> Bear with an old man like me. I am used to the habit that variables
>> get decleared at the begin of a block, not in the middle of it. When
>> searching for the declaration of a variable, I find it a major PITA if
>> I h
Wolfgang Denk wrote:
> It is ugly, but much less ugly than variable declarations right in the
> middle of 200 lines of code.
200-line functions are ugly no matter what variable declaration style
you use. :-)
-Scott
___
U-Boot mailing list
U-Boot@lists.
Timur Tabi wrote:
> Scott Wood wrote:
>
>> It frees the variable up for later such blocks to use. As does
>> declaring iterators inside a for loop, but I guess that's forbidden as
>> well. :-)
>
> I'm not sure whether we want to allow the same variable to be defined
> more than once, even with
Wolfgang Denk wrote:
> Bear with an old man like me. I am used to the habit that variables
> get decleared at the begin of a block, not in the middle of it. When
> searching for the declaration of a variable, I find it a major PITA if
> I have to scan the whole source file instea dof just looking
Premi, Sanjeev wrote:
> Maybe for sometime the usage seems contained. Until someone decides to have
> both the COOL and HOT feature.
And that's why I said that U-Boot can allow in-function variable
declarations, but all variables must have unique names. The only
exception to that rule can be var
Dear Timur Tabi,
In message you
wrote:
>
> I don't see what's wrong with that. The advantage is that the
> variable is close to where it's being used, so that you can see the
> context more easily.
Bear with an old man like me. I am used to the habit that variables
get decleared at the begin
Dear Jerry Van Baren,
In message <49dcff1d.6080...@ge.com> you wrote:
>
> 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 myvarroc
> -Original Message-
> From: Ben Warren [mailto:biggerbadder...@gmail.com]
> Sent: Thursday, April 09, 2009 2:33 AM
> To: Premi, Sanjeev
> Cc: Timur Tabi; Jerry Van Baren; U-Boot-Users ML; Kumar Gala
> Subject: Re: [U-Boot] use of C99
>
> Premi, Sanjeev wrote:
&g
> -Original Message-
> From: Timur Tabi [mailto:ti...@freescale.com]
> Sent: Thursday, April 09, 2009 2:28 AM
> To: Premi, Sanjeev
> Cc: Jerry Van Baren; U-Boot-Users ML; Kumar Gala
> Subject: Re: [U-Boot] use of C99
>
> Premi, Sanjeev wrote:
>
> &
Premi, Sanjeev wrote:
>> -Original Message-
>> From: u-boot-boun...@lists.denx.de
>> [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Timur Tabi
>> Sent: Thursday, April 09, 2009 1:55 AM
>> To: Jerry Van Baren
>> Cc: U-Boot-Users ML; Kumar Gala
Scott Wood wrote:
> It frees the variable up for later such blocks to use. As does
> declaring iterators inside a for loop, but I guess that's forbidden as
> well. :-)
I'm not sure whether we want to allow the same variable to be defined
more than once, even with the same type, inside a functi
Premi, Sanjeev wrote:
> One of the biggest problem is uncontrolled variable definitions that
> gets even nasty when variables have same names with different types;
> though under different set of #ifdefs. Quite possible for commonly
> used variable names - i, ptr, tmp, etc.
Then let's just say th
Timur Tabi wrote:
> On Wed, Apr 8, 2009 at 2:46 PM, Jerry Van Baren
> wrote:
>
>> ACK. I don't expect to see variables spring into life in the middle of
>> nowhere.
>
> I don't see what's wrong with that. The advantage is that the
> variable is close to where it's being used, so that you can
> -Original Message-
> From: u-boot-boun...@lists.denx.de
> [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Timur Tabi
> Sent: Thursday, April 09, 2009 1:55 AM
> To: Jerry Van Baren
> Cc: U-Boot-Users ML; Kumar Gala
> Subject: Re: [U-Boot] use of C99
>
>
On Wed, Apr 8, 2009 at 2:46 PM, Jerry Van Baren wrote:
> ACK. I don't expect to see variables spring into life in the middle of
> nowhere.
I don't see what's wrong with that. The advantage is that the
variable is close to where it's being used, so that you can see the
context more easily.
> I
Hi Wolfgang,
Wolfgang Denk wrote:
> Dear Kumar Gala,
>
> In message <4a0b9aaa-4714-4c27-84a7-22fce4d91...@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
>> fun
Dear Kumar Gala,
In message <4a0b9aaa-4714-4c27-84a7-22fce4d91...@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 c
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.
There are a slew of places that we have something like:
foobar()
{
...
#ifdef CONFIG_COOL_FEATURE
u32 myvarrocks;
#endif
...
#i
29 matches
Mail list logo
