Consequences of using an external function without an external function declaration 
Author Message
 Consequences of using an external function without an external function declaration

Quote:

> My compiler complains about inventing that certain function. Should I be > worried?

Yes. A recent question on another ng dealt with a 'bug report'. 'strtod'
was used without including the header with the declaration, and the
coder then ignored the compiler warning about defaulting the return type
to int.

In this case, strtod returned 1234 when called against "123.4". The
proper inclusion of stdlib.h solved that 'bug'.



Sun, 24 Jun 2001 03:00:00 GMT  
 Consequences of using an external function without an external function declaration

Quote:

> As the subject says, my question is what happens if I should use
> a
> function that is defined in another file but used without an external
> function declaration in the file using this external function. My compiler
> complains about inventing that certain function. Should I be worried?


Oh yes, you should. Never rely on implicit declarations or, even worse,
on a compiler that invents things, aparently out of thin air. There is
a high chance of the compiler inventing the return type wrongly. And the
compiler will not be able to invent argument types for you. And for
variadic functions you will invoke Undefined Behaviour. Plus your
compiler will not be able to check function calls for correct argument
types. It is highly recommended that you use function prototypes at
all times. The keyword "extern" itself is not actually necessary,
but there should always be a proper prototype in scope.

Stephan
(initiator of the campaign against grumpiness in c.l.c)



Mon, 25 Jun 2001 03:00:00 GMT  
 Consequences of using an external function without an external function declaration

Quote:

> Hi,
> As the subject says, my question is what happens if I should use a
> function that is defined in another file but used without an external
> function declaration in the file using this external function. My compiler
> complains about inventing that certain function. Should I be worried?

It depends. Usually you should.

You should know what _happens_ if you are using/calling a function
without a previous visible declaration of this function.

If you use it like this

        a = f(b);

"out of the blue", the compiler will assume that it returns an int and
the compiler expects an int in the place where a function returning an
int would put it. If in fact f returns a double, f may put a double in
the same place or possibly in another place. In any case the compiler
would extract an int from the call which is certainly wrong if the
function returns a double. Even if 'a' is declared as 'double' the
result will not be "the" double f returned but a conversion to double
of some "misinterpreted" int. Moreover your program produces undefined
behaviour and may crash.

Moreover, without a previous declaration of the function it is
mandatory

a) that the numbers of actual arguments passed to the "invented"
functions agrees with the number of parameters in the actual
definition of the function.

b) that the types of the actual arguments after promotion are
compatible (in practice this means "identical") to the types of the
parameters of the function which is actually called.

(If you call an "invented" function, any argument type of
char,short,int and unsigned varieties which fits into an int will be
implicitly promoted to an int otherwise to unsigned and float will be
implicitly promoted to double. Thus the "type after promotion" for
arithmetic input for types "smaller" than int/unsigned or double is
int/unsigned or double).

Thus without explicit knowledge about the actual definition of the
function to be called it is always dangerous to call this function.
If you know the definition of the function it doesn't cost anything to
include a matching declaration before calling it.

Is this just a theorerical question or a practical problem ?

Regards
Horst



Mon, 25 Jun 2001 03:00:00 GMT  
 Consequences of using an external function without an external function declaration

Quote:

>Thanks to all who replied.

>The good thing is that the compiler is saying its inventing "extern
>int function_name()" which is what the actual function returns.

Yes, that's the type that the C language specifies must be assumed if
no declaration is in scope

Quote:
>Anyway the return value is never used so that would never cause a problem.

Wrong. If you call a function through the wrong type you get undefined
behaviour ranging from it appearing to work correctly to it crashing
horribly. Whether the return value is used or not is not relevant to this.

Quote:
>But does the empty bracket mean that the function takes no parameters?

In a function definition it would. In a plain declaration such as here
it indicates a fixed but unspecified number of non-promotable parameters
(i.e. no char, short or float parameters).

Quote:
>The
>real function takes an integer arguement which is used. Now would the
>arguement that is passed through the funcion call then be discarded
>or does it all end happily and the function gets the passed parameter?

As long as the function is defined as taking an int parameter with an
int return type it will work.

Quote:
>Eg.

>In file b.c which contains the call to the function in a.c
>----------------------------------------------------------
>    /* no function declarations for function_name */
>    .
>    .
>    function_name(arg1);
>    .
>    .

>In file a.c which contains the actual function definition
>---------------------------------------------------------
>    int function_name (int arg1) {
>      .
>      /* some manipulations with arg1 */
>      .
>    }

>Will the manipulations with arg1 in function_name have the
>passed value or will it be pure gibberish?

This is OK although it isn't good style. Also the C language will cease
to support this sort of thing in a year or so.

- Show quoted text -

Quote:
>In answer to someone's inquiry, yes, this is a practical question though
>I can't be sure if its a problem yet (which is what I'm trying to
>determine from this post). This "mistake" occurs in a part of the code
>(more specifically the underlying OS used) for which I have not part in
>writing. The OS is an in-house development that is used in other in-house
>developed software. Other engineers who have more experience with it use
>the same code for their software. It strikes me as surprising that it
>would have been left in there for such a long time without a fix. Given
>that everyone else at my place seems to treat it like its something
>trivial and not worth fixing, should I go against the flow when everyone
>is just drifting down river? I'm kinda new at this place and the last
>thing I want to be, is to appear like a brash know-it-all out to make
>waves and rock the boat. Sorry, this is sounding much like something
>written to an agony column but anyway back to my original question: Is
>it worth fixing? As pointed out by everyone: a simple inclusion of the
>function declaration solves it all. Given that the fix is so simple why
>hasn't anyone else done it?

It used to be common practice, especially in pre-ANSI days. However as
I noted it isn't good practice now. If it is easy to fix then it should
be fixed.

--
-----------------------------------------


-----------------------------------------



Sat, 30 Jun 2001 03:00:00 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. Importing functions from external DLL (without headers etc.)

2. execv function fails when used as an Oracle external stored procedure

3. Coding Idioms For Functions Having External Linkage

4. 1 function that is unresolved external?

5. External call to asm function>?

6. Problem with external functions

7. dynamic parameter list for external function

8. stuct alignment & external functions

9. Calling external functions with incorrect parameters

10. Calling an external function from input

11. Q: How to properly declare external macros/inline functions

12. Creating external functions.

 

 
Powered by phpBB® Forum Software