[Icc-avr] Are 'local' vars in main automatuc or in bss?

[Albert vanVeen]

Now we're getting in linguistics, even more intersting.
The problem then is of course the well-known inconsistencies and ambiguities of language. Therefore, when discussing programming languages, one has to ignore what terms as "declare" mean in human English, just what it is defined to be in C or Pascal or your favourite language.
But I must say (1==x) is seriously ugly and unreadable.

Your name has long suggested that we share a nativity (fortunately for you not a naivety).
But yes, every discussion must to an end, unless you are in politics (or a university).

Groeten,
Albert.


-----Original Message-----
From: icc-avr-bounces at imagecraft.com [mailto:icc-avr-bounces at imagecraft.com] On Behalf Of Jaspers, Ton
Sent: Wednesday, October 31, 2007 09:30 PM
To: Discussion list for ICCAVR and ICCtiny Users. You do NOT need to subscribeto icc-announce if you are a member of this.
Subject: RE: [Icc-avr] Are 'local' vars in main automatuc or in bss?

 

> -----Original Message-----
> From:  David Brown
> Jaspers, Ton wrote:
> >> From: David Brown
> >> Jaspers, Ton wrote:
> >>>> From: David Brown
......


> > 
> > They are not declarations, they are function prototypes. 
> > 
> 
> I believe you are wrong here.  I don't know I'll be able to do a good 
> job of explaining this, but it's probably well beyond the interest of 
> most iccavr list readers, and more suitable for the comp.lang.c group.
> 
> A prototype is a function declaration that gives the type information 
> for the function.  Non-prototype declarations were used in early K&R C 
> code, but have been deprecated at least since C89 and cause warnings 
> or errors in many compilers:
> 
> // Non-prototype declarations:
> foo();
> extern foo();
> 
> // Prototype declarations:
> int foo(int x);
> extern int foo(int x);
> 
> 
> A "declaration" is a statement that tells the compiler about a name - 
> you cannot have a "prototype" that is not a declaration.  The term 
> "prototype" is often used to refer to a function declaration that is 
> not a definition (i.e., "int foo(int x);" without a function body) - 
> but strictly speaking, a function definition is also a declaration and 
> a prototype (unless you allow out-of-date K&R style functions).
> 
> 

Perhaps its a language thing (I am not a native English speaker).

Int foo(int x);  /* is what I am used to call a prototytpe */
Int foo(int x)   /* us what I am used to call a declaration */ 
{
  Some code ....
}

Hence my remark:

> > 
> > Never declare a function in a header!
> > 
> 




> >> Private and public members
> >> of a class
> >> have the same linkage and scope - it's just that the 
> private members 
> >> are hidden by the compiler from direct access for functions other 
> >> than methods of the same class (or its friends).
> > 
> > In other words, they have a different scope..... 
> > 
> 
> No, they have the same scope - but different access.
>

Uhh, that again is a liguistic difference. 
>From a programmers view:
Private : not accesible from outside the module/class/wò-èva.
Public: : Accecible from the outside of ....
Hence a different scope, unless my understanding of the English language 
is wrong, which is not impossible since I am not a native English speaker

> 
> *You* check it - !0 gives 1 on any compiler I have tried.  
> It's also important to note that the operators ==, !=, <=, <, 

As stated before, I have no appetite getting into the boolean debate 
again. As far as I am concerned it stops here. But if you like 
You cab read back my views on usenet (dejaview), they date back as far 
as 1980. Everyone is entiteled an opinion, even a false one. 



> You can't have a true boolean in C, as there is no way to 
> type-check the boolean.  

Shy, that is what I said al allong....




> > So far MISRA is the best (only) coding standard that seems 
> to be widely 
> > accepted in the industry. That in itself makes it a great standard. 
> > 
> 
> That's true - but it doesn't make it perfect.  While most 
> rules in MISRA 
> make sense, there are lots of ugly rules that do not.  For example, 
> MISRA says you should write "if (1 == x) ..." rather than "if 
> (x == 1)", 
> so that the common typo of using "=" instead of "==" is caught by the 
> compiler.  It is far better to write the readable and clear 
> form "if (x 
> == 1)", and use a compiler (or linter) that will catch the typo.

Use it pragmatically. My project specifications usually detail the 
aplicable MISRA parts. By making a selection it becoms a very usefull 
tool. Basically that is what happens with most of the standards references. 
Specifying a standard without detailing the aplicable parts is never a good 
idea, regardless what standard is about.  




> But I am not going to 
> advocate using an old-fashioned, ugly (IMHO, of course), and 
> inconsistent convention just because lots of other people use it.

<....>




 



_______________________________________________
Icc-avr mailing list
Icc-avr at imagecraft.com
http://dragonsgate.net/mailman/listinfo/icc-avr

Scanned by Bizo Email Filter