Re: function call with arguments which takes no arguments

From: Neo (timeless_illusion_at_yahoo.com)
Date: 01/21/05


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



Relevant Pages

  • Re: I have a problem in my study
    ... Is the wrong with the compiler? ... its normal to declare function prototypes outside main. ... It is normal to declare a prototype where it gets used. ... the OP had declared c as int - and getcdoes not return char ...
    (comp.lang.c)
  • Re: float() function
    ... int test_function ... float input_float; ... not to use prototypes. ... when the compiler sees a ...
    (comp.lang.c)
  • Re: derangement: coding review request
    ... >Q) Good form has prototypes before the main call. ... The partof the prototype arguments that matter *to the compiler* ... of type "pointer to char" and one of type "int", ... While the computer does not care, I will say that *I* care, and ...
    (comp.lang.c)
  • Re: Boost process and C
    ... What "original K&R prototypes" are you talking about? ... style of function declarations: ... int main ... extern char *fn; ...
    (comp.lang.c)
  • Re: Is it a good thing that program mix C and C++?
    ... the malloc-and-friends prototypes. ... bets are off as to what happens when the compiler takes what it ... thinks is an int return and casts it into your pointer. ...
    (comp.lang.c)