Re: [U-Boot] use of C99
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 >> >> u32 indx_CONFIG_HOT_FEATURE > > Then please read the Coding Style about how to chose variable names. > > Best regards, > > Wolfgang Denk No matter how many times I like at the code snippet above, my brain insists on seeing two #define constants named "CONFIG_COOL_FEATURE" and "CONFIG_HOT_FEATURE". I once tried to deal with C code whose author had used some all-caps variable names. It was like getting a rental car with the gas pedal on the left and the break on the right. No matter how aware intellectually you were of this quirk, the car would be virtually undrivable. That's one reason consistent coding styles are important. The brain also has a harder time dealing with two things that are almost the same than with two things that differ greatly. For example, if I knew French, I'm sure I would have no difficulty writing "centre". However, being a native speaker of American English, if I needed to write with traditional British spelling, I'm sure I'd screw up and writer "center" for "centre" at least half the time. Personally, I prefer allowing variables to be declared anywhere, but I don't want the hidden cost of allowing U-Boot to be a little bit different from the Linux kernel to be underestimated. There is one place the styles differ already -- the use of a space between a function name and the following left parenthesis. The result is a mishmash, and just makes it harder to search the code base for function names. Best regards, Larry ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] use of C99
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@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] use of C99
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_FEATURE Then please read the Coding Style about how to chose variable names. 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: w...@denx.de Imitation is the sincerest form of plagarism. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] use of C99
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
Re: [U-Boot] use of C99
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_CONFIG_HOT_FEATURE > > Matt Harper > Tehama Wireless Ewww. Quoting from Documentation/CodingStyle: Chapter 4: Naming C is a Spartan language, and so should your naming be. Unlike Modula-2 and Pascal programmers, C programmers do not use cute names like ThisVariableIsATemporaryCounter. A C programmer would call that variable "tmp", which is much easier to write, and not the least more difficult to understand. [snip] LOCAL variable names should be short, and to the point. If you have some random integer loop counter, it should probably be called "i". Calling it "loop_counter" is non-productive, if there is no chance of it being mis-understood. Similarly, "tmp" can be just about any type of variable that is used to hold a temporary value. If you are afraid to mix up your local variable names, you have another problem, which is called the function-growth-hormone-imbalance syndrome. See chapter 6 (Functions). Best regards, gvb ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] use of C99
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 CONFIG_HOT_FEATURE > u32 i; > void* ptr; > ... > ... > #endif > > Maybe for sometime the usage seems contained. Until someone > decides to have both the COOL and HOT feature. 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_CONFIG_HOT_FEATURE Matt Harper Tehama Wireless ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] use of C99
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 Linux coding style saves a lot of time and > headaches. IMO, this is worth the occasional clumsiness that results. Code seems to flow from Linux to u-boot more than the reverse -- I don't see much of a problem with being more permissive. > BTW, the Linux kernel does not avoid all C99 features. For example, it > relies heavily on named initialization of structs. However, AFAICT, it > shuns those C99 feature that originated in C++. I suspect that has more to do with people's feelings toward C++ than any unbiased assessment of the merits of the features. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] use of C99
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 that results. BTW, the Linux kernel does not avoid all C99 features. For example, it relies heavily on named initialization of structs. However, AFAICT, it shuns those C99 feature that originated in C++. Best regards, Larry ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] use of C99
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 your life will be easier >> if you get a car also. > > The person with the bicycle might ask you why you require him to > contribute to air pollution and climate changes and all these things > when you could as well put the target he has to reach just 200 meters > from his home. Not everything that can be done is a good thing to do. Indeed, having the variable declaration close by to where it's used *does* make things easier. :-) -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] use of C99
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 you get a car also. The person with the bicycle might ask you why you require him to contribute to air pollution and climate changes and all these things when you could as well put the target he has to reach just 200 meters from his home. Not everything that can be done is a good thing to do. 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: w...@denx.de Computers are not intelligent. They only think they are. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] use of C99
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 at the code at work, or on a friends computer? Then it will be more difficult for you. I have this problem sometimes. That's why I try to avoid using another tool as much as possible. 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 you get a car also. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] use of C99
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 have to scan the whole source file instea dof just looking at the >> first few lines of a block. I'll second that > > This is why I use an advanced programmer's editor that brings me to the > definition of the variable under the cursor with a single keystroke. > What if _MY_ favourite editor doesn't. Or what if I don't have access to it because I'm looking at the code at work, or on a friends computer? >> Not the compiler, but humans like me. I have just a small window of >> lines I can really focus on, and the smaller a block of code >> (including the needed variable declarations), the easier I get the >> impression I understand it. That is the key - half the time #ifdef COOL_FEATURE in the middle of a function really means that the feature needs to be put in another function > > In this case, it would be easier for you if the variable were declared > next to the code that uses it. True and correct, but it can often be done so in another function > >>> This is what we do today, and I think it's ugly. >> >> It is ugly, but much less ugly than variable declarations right in the >> middle of 200 lines of code. 200 lines of code is much more ugly Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] use of C99
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.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] use of C99
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 the same type, inside a function.
What's wrong with this:?
for (i = 0; i < n; i++) {
int j;
...
}
for (i = 0; i < m; i++) {
int j;
...
}
>> Chances are it will allocate all stack space for all variables up front,
>> regardless of where they're declared.
>
> Yes, but it many cases it won't allocate any stack space at all because
> it will just keep the variable in a register. My point was that if a
> variable is defined later in a function, then it's more likely to have
> limited scope, so the compiler will be more likely to use a register
> instead of stack to store it.
I don't think it will make a difference. The compiler knows what the
lifetime of the variable is, regardless of where you declare it.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] use of C99
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 at the > first few lines of a block. This is why I use an advanced programmer's editor that brings me to the definition of the variable under the cursor with a single keystroke. > Not the compiler, but humans like me. I have just a small window of > lines I can really focus on, and the smaller a block of code > (including the needed variable declarations), the easier I get the > impression I understand it. In this case, it would be easier for you if the variable were declared next to the code that uses it. >> This is what we do today, and I think it's ugly. > > It is ugly, but much less ugly than variable declarations right in the > middle of 200 lines of code. This is where I disagree. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] use of C99
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 variables declared at the top of iterators. That's just my two cents. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] use of C99
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 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 at the
first few lines of a block.
> I don't see what the value is of limiting the lifetime of the
> variable. The compiler isn't going to use that as a hint, anyway.
Not the compiler, but humans like me. I have just a small window of
lines I can really focus on, and the smaller a block of code
(including the needed variable declarations), the easier I get the
impression I understand it.
> It's just going to use this for syntax checking. If you define and
> initialize a variable at the top of the function, but don't use that
> variable until a hundred lines later, the compiler is going to
> initialize the variable when it's first used, not when the function is
> first entered. Chances are it's not even going to define stack space
> for it.
Keep in mind that we don't write the code for the compiler, but for
the human being that comes after us and that has to maintain that
code.
> > #ifdef CONFIG_COOL_FEATURE
> >{
> >u32 myvarrocks = foo * bar * bar;
> >
> >gd->neato = myvarrocks
> >}
> > #endif
> >
> > Is this an acceptable compromise?
>
> This is what we do today, and I think it's ugly.
It is ugly, but much less ugly than variable declarations right in the
middle of 200 lines of code.
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: w...@denx.de
At the source of every error which is blamed on the computer you will
find at least two human errors, including the error of blaming it on
the computer.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] use of C99
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 myvarrocks = foo * bar * bar;
>
> gd->neato = myvarrocks
> }
> #endif
>
> Is this an acceptable compromise?
Yes, if really necessary, this can be done.
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: w...@denx.de
Of all the things I've lost, I miss my mind the most.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] use of C99
> -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: > >> -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. > >> > >> > >>> 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. > >>> > >> I don't see what the value is of limiting the lifetime of the > >> variable. The compiler isn't going to use that as a hint, anyway. > >> It's just going to use this for syntax checking. If you define and > >> initialize a variable at the top of the function, but > don't use that > >> variable until a hundred lines later, the compiler is going to > >> initialize the variable when it's first used, not when the > function is > >> first entered. Chances are it's not even going to define > stack space > >> for it. > >> > > > > 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. > > > > > I'm showing extreme ignorance here, but does C99 let you do this? > > for (int i = 0; i < x ; i++) ? That's much better contained than declaring in a ifdef. > Doing a lot of C++ has rotted my brain, but this is one thing I like. I love C++; still avoid declare as you go. Iterators (as you mention above) are only exception. ~sanjeev > > regards, > Ben > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] use of C99
> -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: > > > 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 that if you're going to define a variable in the > middle of a function, it can't have the same name as another > variable in > that function. > > > I feel, here, ifdefs provide a false sense of 'enclosure' > with possibility > > of frequent breaches - in code (while implementing) and in > simple reading > > (for understanding). > > Sorry, I don't understand what you're talking about. The #ifdefs are > used to enable feature-specific code on platforms that have > that feature. 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 CONFIG_HOT_FEATURE u32 i; void* ptr; ... ... #endif Maybe for sometime the usage seems contained. Until someone decides to have both the COOL and HOT feature. ~sanjeev > > -- > Timur Tabi > Linux kernel developer at Freescale > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] use of C99
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 >> 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. >> >> >>> 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. >>> >> I don't see what the value is of limiting the lifetime of the >> variable. The compiler isn't going to use that as a hint, anyway. >> It's just going to use this for syntax checking. If you define and >> initialize a variable at the top of the function, but don't use that >> variable until a hundred lines later, the compiler is going to >> initialize the variable when it's first used, not when the function is >> first entered. Chances are it's not even going to define stack space >> for it. >> > > 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. > > I'm showing extreme ignorance here, but does C99 let you do this? for (int i = 0; i < x ; i++) ? Doing a lot of C++ has rotted my brain, but this is one thing I like. regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] use of C99
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 function. > Chances are it will allocate all stack space for all variables up front, > regardless of where they're declared. Yes, but it many cases it won't allocate any stack space at all because it will just keep the variable in a register. My point was that if a variable is defined later in a function, then it's more likely to have limited scope, so the compiler will be more likely to use a register instead of stack to store it. >> This is what we do today, and I think it's ugly. > > Yes. But not as ugly as having two #ifdef blocks. Agreed, but I don't consider it to be much of a compromise. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] use of C99
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 that if you're going to define a variable in the middle of a function, it can't have the same name as another variable in that function. > I feel, here, ifdefs provide a false sense of 'enclosure' with possibility > of frequent breaches - in code (while implementing) and in simple reading > (for understanding). Sorry, I don't understand what you're talking about. The #ifdefs are used to enable feature-specific code on platforms that have that feature. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] use of C99
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 see the
> context more easily.
Agreed. In many cases it reduces clutter by eliminating the need for
separate declaration and assignment.
> I don't see what the value is of limiting the lifetime of the
> variable.
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. :-)
> It's just going to use this for syntax checking. If you define and
> initialize a variable at the top of the function, but don't use that
> variable until a hundred lines later, the compiler is going to
> initialize the variable when it's first used, not when the function is
> first entered. Chances are it's not even going to define stack space
> for it.
Chances are it will allocate all stack space for all variables up front,
regardless of where they're declared.
>> #ifdef CONFIG_COOL_FEATURE
>>{
>>u32 myvarrocks = foo * bar * bar;
>>
>>gd->neato = myvarrocks
>>}
>> #endif
>>
>> Is this an acceptable compromise?
>
> This is what we do today, and I think it's ugly.
Yes. But not as ugly as having two #ifdef blocks.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] use of C99
> -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.
>
> > 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.
>
> I don't see what the value is of limiting the lifetime of the
> variable. The compiler isn't going to use that as a hint, anyway.
> It's just going to use this for syntax checking. If you define and
> initialize a variable at the top of the function, but don't use that
> variable until a hundred lines later, the compiler is going to
> initialize the variable when it's first used, not when the function is
> first entered. Chances are it's not even going to define stack space
> for it.
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.
I feel, here, ifdefs provide a false sense of 'enclosure' with possibility
of frequent breaches - in code (while implementing) and in simple reading
(for understanding).
~sanjeev
> > #ifdef CONFIG_COOL_FEATURE
> > {
> > u32 myvarrocks = foo * bar * bar;
> >
> > gd->neato = myvarrocks
> > }
> > #endif
> >
> > Is this an acceptable compromise?
>
> This is what we do today, and I think it's ugly.
>
> --
> Timur Tabi
> Linux kernel developer at Freescale
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
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.
> 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.
I don't see what the value is of limiting the lifetime of the
variable. The compiler isn't going to use that as a hint, anyway.
It's just going to use this for syntax checking. If you define and
initialize a variable at the top of the function, but don't use that
variable until a hundred lines later, the compiler is going to
initialize the variable when it's first used, not when the function is
first entered. Chances are it's not even going to define stack space
for it.
> #ifdef CONFIG_COOL_FEATURE
> {
> u32 myvarrocks = foo * bar * bar;
>
> gd->neato = myvarrocks
> }
> #endif
>
> Is this an acceptable compromise?
This is what we do today, and I think it's ugly.
--
Timur Tabi
Linux kernel developer at Freescale
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] use of C99
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
>> 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
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] use of C99
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 code extremely ugly and hard to read and understand. > 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. 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: w...@denx.de Life is a process, not a principle, a mystery to be lived, not a problem to be solved. - Gerard Straub, television producer and author (stolen from Frank Herbert??) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] use of C99
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
...
#ifdef CONFIG_COOL_FEATURE
myvarrocks = foo * bar * bar;
gd->neato = myvarrocks
#endif
it would be nice to just have:
foobar()
{
...
#ifdef CONFIG_COOL_FEATURE
u32 myvarrocks = foo * bar * bar;
gd->neato = myvarrocks
#endif
- k
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
