Re: function call with arguments which takes no arguments
From: Neo (timeless_illusion_at_yahoo.com)
Date: 01/21/05
- Next message: Andrew Ryan Chang: "Re: Cell Architecture Explained (MASSIVE AMOUNT OF INFO)"
- Previous message: R Adsett: "Re: Serial+power over single coax cable"
- In reply to: Jack Klein: "Re: function call with arguments which takes no arguments"
- Next in thread: Hans-Bernhard Broeker: "Re: function call with arguments which takes no arguments"
- Reply: Hans-Bernhard Broeker: "Re: function call with arguments which takes no arguments"
- Reply: CBFalconer: "Re: function call with arguments which takes no arguments"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 21 Jan 2005 11:23:49 +0530
"Jack Klein" <jackklein@spamcop.net> wrote in message
news:gmduu0pjtt625jpe6l0otdfopk75m6dnr0@4ax.com...
> On Wed, 19 Jan 2005 15:59:33 +0530, "Neo"
> <timeless_illusion@yahoo.com> wrote in comp.arch.embedded:
>
>> Why the following code is compilable? The function abc() doesn't take any
>> arguments, still i can call the function with arbitraty number of
>> arguments.
>> Even compiler doesn't show any warning. What the standard says?
>>
>> ----- file1.c ------
>> extern unsigned abc();
>> int main()
>> {
>> unsigned *chip_offset;
>> abc(&chip_offset, 10);
>> /* do something with pointer - which is errornous */
>> return 0;
>> }
>>
>> ----- file2.c -----
>> unsigned abc()
>> {
>> unsigned some_address;
>> some_address = 0xFFBA;
>> return some_address;
>> }
>>
>>
>> -Neo
>> "If you don't program yourself, life will program you!"
>
> C allows function declarations with empty parentheses for backwards
> compatibility with code from before the ANSI standard, when the
> language did not have prototypes.
>
> The C standard specifically states that when you call a function
> without having a prototype in scope, if the call does not have the
> correct number and type of parameters, the behavior is undefined.
> That means it is strictly up to the programmer to make sure he gets it
> correct if he/she chooses NOT to use prototypes. A compiler is NEVER
> required to warn you about undefined behavior, and the C standard
> washes its hands of any responsibility for the result.
>
> There is no possible excuse at all for not using prototypes in all
> function declarations and definitions in C. Prototypes are the single
> most significant and important improvement in the 30+ year history of
> the language. Anyone who claims to be a professional C programmer and
> ever fails to use a prototype is deluding themselves.
>
> Empty parentheses should never appear in a function declaration or
> definition in C. NEVER.
>
> In a later post in the thread, you talked about using TI's Code
> Composer Studio. I use if for a different DSP family, so I don't know
> if yours is the same, but you don't want the "strict ANSI" setting on
> the Parser page. See if you have a check box for "Issue Nonserious
> Warnings" on the Diagnostics page.
>
> That probably won't catch this particular error, since it might equate
> the non-prototype declaration as a prototype, but I don't know for
> sure because such things never appear in my code.
>
> If you are going to be a professional programmer, start learning some
> basic rules now:
>
> 1. The 'extern' keyword should NEVER appear in a source code file.
>
> 2. There should NEVER be a function prototype in a source code file,
> unless it has the function is static and defined in the same source
> code file.
>
> 3. All functions not static, and all external data, MUST be
> prototypes and/or declared in a header, and that header MUST be
> included by the source file that defines the function/data as well as
> every source file that calls/references the externals.
>
> 4. There are no function declarations or definitions with (). ALL
> function declarations MUST be full prototypes. There is no "int
> main()", there is ONLY "int main(void)". There is no "extern unsigned
> abc()", there is ONLY "extern unsigned int abc(void)".
>
> If you do this right, the compiler will catch every single mis-matched
> function call.
>
> Some programmers think they are too experienced or too talented to
> have to follow what they consider "nit picky" rules like this. That
> is just a case of their egos outweighing their judgment. If you don't
> code like this, you are an accident waiting to happen, and it WILL
> happen, no matter how good or experienced you are.
>
> --
> Jack Klein
> Home: http://JK-Technology.Com
> FAQs for
> comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
> comp.lang.c++ http://www.parashift.com/c++-faq-lite/
> alt.comp.lang.learn.c-c++
> http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
Very Good Explanation of function Prototypes..... this is often overlooked
by most C programmers or 'coz of lazziness.
One point em nt clear about is What is the use of extern keyword in a
function prototype. Should we use or not use extern keyword in a function
prototype and WHY? Lets say for eg. :
------ main.c -----
#include "file1.h"
#include "abc.h"
int main(void)
{
int i;
i = sum(2,3);
abc();
return 0;
}
-------- file1.h -------
#ifndef __FILE1_H__
#define __FILE1_H__
int sum(int a, int b);
#endif
-------- file1.c-------
#include "file1.h"
int sum(int a, int b)
{
return (a+b);
}
------abc.h------
#ifndef __ABC_H__
#define __ABC_H__
void abc(void);
#endif
-------abc.c------
#include "abc.h"
#include "file1.h"
void abc(void)
{
int i;
i = sum(22,33);
}
I compile the above Program as follows :
gcc main.c file1.c abc.c -ansi -Wall -pedantic -Wstrict-prototypes
Clean compilation no warnings. O'kay!
Now, should I declare int sum(int a, int b); as
extern int sum(int a, int b); in file1.h
if so, why???? (I've seen some ppl. do that way).
and there is also practice to code it something like this
#ifdef __FILE1_C__
#define FILE1_EXTERN
#else
#define FILE1_EXTERN extern
#endif
FILE1_EXTERN int sum(int a, int b);
A8.1 ...."objects and functions declared outside a function are taken to be
static, with external linkage."
K&R II Page 211. What is the meaning of the above line???
Thanks,
-Neo
- Next message: Andrew Ryan Chang: "Re: Cell Architecture Explained (MASSIVE AMOUNT OF INFO)"
- Previous message: R Adsett: "Re: Serial+power over single coax cable"
- In reply to: Jack Klein: "Re: function call with arguments which takes no arguments"
- Next in thread: Hans-Bernhard Broeker: "Re: function call with arguments which takes no arguments"
- Reply: Hans-Bernhard Broeker: "Re: function call with arguments which takes no arguments"
- Reply: CBFalconer: "Re: function call with arguments which takes no arguments"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|