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

[David Brown]

Jaspers, Ton wrote:
>  
> 
>> -----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).
> 

I hadn't noticed - you write better than many native speakers.  In this 
case, the words mean what the C standards want them to mean, rather than 
necessarily the standard usage in English.

> 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!
>>>

Suddenly your comments make much more sense!

When you say "declare", what you really mean is "define", and when you 
say "prototype", what you really mean is "declaration".  The difference 
is that a "definition" says exactly what something is (i.e., the 
function body for a function, or the space allocation and possibly 
initial value for a variable), while a "declaration" simply tells that 
compiler that the object in question exists somewhere.  For any object 
you use in the program, there must be exactly one definition, but there 
can be many declarations (typically in an included header).  A 
definition is itself a declaration as well.


Of course, there is an exception to your rule - inline functions can 
very well be defined in headers.  I don't know if iccavr supports inline 
functions yet (I only have an old version), but they are common in other 
compilers, and in particular in C++ programming.  Inline functions which 
are exported by a module must be defined in the header file - otherwise, 
they cannot be inlined in other modules.  For example, if you want to 
replace the macro:

#define max(a, b) (((a) > (b)) ? (a) : (b))

with a type-safe version that avoids nasties when calling max(*p++, x++) 
you use:

static inline max(int a, int b) { return (a > b) ? a : b; }

This inline function, which is a definition, must go in a header if it 
is to be used in different modules.


> 
>>>> 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. 

Again, "scope" and "access" are terms defined by the C (and C++) 
language standards - you don't get to use your own definition here.

>>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
> 

Arguably you could use the word "scope" as a general English word in 
this way, but the term "scope" in programming (not just for C) is much 
more specific.  There are lots of terms that are used differently in the 
context of programming languages compared to normal English language usage.

>> *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. 
> 

OK, we'll leave it there (unless any others in the mailing list are 
interested).

> 
> 
>> 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.  
> 

I fully agree here.

> 
> 
> 
>> 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.
> 
> <....>
>