Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > program having printf() function invocation without including <stdio.h>

Reply
Thread Tools

program having printf() function invocation without including <stdio.h>

 
 
sam_cit@yahoo.co.in
Guest
Posts: n/a
 
      01-13-2007
Hi Everyone,

int main()
{
printf("not included stdio.h");
}

Yes, i haven't included stdio.h and my compiler would generate a
warning and would assume that it would return a int, my question is how
does the linker manage to link the function invocation to the proper
printf function?
and does including a header file having function prototype help the
linker in any way?

 
Reply With Quote
 
 
 
 
Kenny McCormack
Guest
Posts: n/a
 
      01-13-2007
In article <(E-Mail Removed). com>,
<(E-Mail Removed)> wrote:
>Hi Everyone,
>
> int main()
> {
> printf("not included stdio.h");
> }
>
> Yes, i haven't included stdio.h and my compiler would generate a
>warning and would assume that it would return a int, my question is how
>does the linker manage to link the function invocation to the proper
>printf function?
> and does including a header file having function prototype help the
>linker in any way?


The droids will tell you that this is undefined behavior, for all the
usual drecky reasons.

 
Reply With Quote
 
 
 
 
santosh
Guest
Posts: n/a
 
      01-13-2007
(E-Mail Removed) wrote:
> Hi Everyone,
>
> int main()
> {
> printf("not included stdio.h");
> }
>
> Yes, i haven't included stdio.h and my compiler would generate a
> warning and would assume that it would return a int, my question is how
> does the linker manage to link the function invocation to the proper
> printf function?
> and does including a header file having function prototype help the
> linker in any way?


The prototype is primarily for the compiler's benifit, as it specifies
the number and type of parameters the function expects, if any, and the
type of value it returns, if any. It helps the compiler to output the
correct object code when the function is called and to perform the
correct conversions on the return value.

The linker will simply search the library archive files specified for
the label 'printf'/'_printf' and link in the object code. It doesn't
need the function's prototype.

Strictly according to the standard calling a function whose prototype
is not in scope leads to undefined behaviour. It might work for simpler
functions on some implementations. Some compilers like gcc, often have
the ability to "magically" recognise certain common functions and
include the code inline, but all these are implementation specific
behaviour. You cannot portably rely on them.

 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      01-13-2007
http://www.velocityreviews.com/forums/(E-Mail Removed) a écrit :
> Hi Everyone,
>
> int main()
> {
> printf("not included stdio.h");
> }
>
> Yes, i haven't included stdio.h and my compiler would generate a
> warning and would assume that it would return a int, my question is how
> does the linker manage to link the function invocation to the proper
> printf function?
> and does including a header file having function prototype help the
> linker in any way?
>


1) Linkers deal with object files, this has nothing to do with header
files.
2) Header files describe interfaces of functions and modules. This has
nothing to do with object files.

Please keep those apart.

Now, the interfaces descriptions are for the compiler, that generates
code according to those descriptions.

When (in C ) a prototype is not in scope, an automatic
prototype is provided by the compiler. It assumes a function that
has an undertemined number of arguments and returns an int.

In both cases, whether a prototype is in scope or not,
an external reference to a function is issued by the compiler.
In this case the object code would contain an external
reference to the function "printf" (or "_printf", it depends
on the compiler).

The linker goes through the object files and sees:
"Mmmm this is an external reference to the printf function.
Let's look if I find it somewhere".

Then, depending on the linker, it will find it or not in the
libraries it uses BY DEFAULT.

Default libraries vary from compiler system to compiler system.
At least the startup code is ALWAYS automatically included,
then, most compilers assume the C library as a default
library, i;e. one that you do not need to include in the
linker command line. Other compilers may differ, for example some
braindead compiler systems force you to write the math
library as an extra command line option, and it is not
included by default, so if you use the sqrt function for
instance, compilation will fail unless you tell the linker to
add the math library.

Others will include a lot of default libraries so that your
code mostly will link without specifying any extra library
Microsoft Visual C for instance will include all these:

comctl32.lib shlwapi.lib kernel32.lib user32.lib gdi32.lib
winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib
oleaut32.lib uuid.lib odbc32.lib odbccp32.lib

Other compiler systems will be less bloated, for instance
lcc-win32 includes just 6-7 libraries.

Then, the answer to your question is simple:
The linker finds the printf function in the C library of
the compiler that is included by default.

jacob



 
Reply With Quote
 
Christopher Benson-Manica
Guest
Posts: n/a
 
      01-13-2007
santosh <(E-Mail Removed)> wrote:

> Strictly according to the standard calling a function whose prototype
> is not in scope leads to undefined behaviour.


That's not completely true. Calling a variadic function like printf()
without its prototype in scope yields UB. I'm not enough of a
language lawyer to parse 6.5.2.2 for you, but the fact that Annex J.2
is at pains to note when a function call without a function prototype
yields UB seems to indicate that there are cases where the behavior is
not undefined.

--
C. Benson Manica | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com | don't, I need to know. Flames welcome.
 
Reply With Quote
 
Richard Heathfield
Guest
Posts: n/a
 
      01-13-2007
(E-Mail Removed) said:

> Hi Everyone,
>
> int main()
> {
> printf("not included stdio.h");
> }
>
> Yes, i haven't included stdio.h


and so you have called a variadic function without a valid prototype in
scope, as a result of which the behaviour of the program is undefined.

May I recommend "The C Programming Language", 2nd edition, by Brian W
Kernighan and Dennis M Ritchie? Reading it (slowly - its information
density is extremely high) will answer many of your questions.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      01-13-2007
Christopher Benson-Manica <(E-Mail Removed)> writes:
> santosh <(E-Mail Removed)> wrote:
>
>> Strictly according to the standard calling a function whose prototype
>> is not in scope leads to undefined behaviour.

>
> That's not completely true. Calling a variadic function like printf()
> without its prototype in scope yields UB. I'm not enough of a
> language lawyer to parse 6.5.2.2 for you, but the fact that Annex J.2
> is at pains to note when a function call without a function prototype
> yields UB seems to indicate that there are cases where the behavior is
> not undefined.


In C99, you can't call a function unless a declaration for it is
visible, but that declaration needn't be a prototype (i.e., it needn't
specify the parameter types). It *should*, and there's no good reason
not to, but non-prototype declarations are allowed for backward
compatibility.

For example:

void foo();

...

foo("hello", 42);

This is ok if the *definition* of foo() specifies that it returns
void, has two parameters of types char* and int, and that it's not
variadic.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
 
Reply With Quote
 
Richard Tobin
Guest
Posts: n/a
 
      01-14-2007
In article <(E-Mail Removed)>,
Keith Thompson <(E-Mail Removed)> wrote:

>In C99, you can't call a function unless a declaration for it is
>visible, but that declaration needn't be a prototype


In C90 and earlier, if you call a function without a declaration it
will be assumed to return int, and its arguments will be subject to
the default promotions, and it will be assumed to be non-variadic
(variadic functions might have a different calling convention).

In practice, most compilers by default just warn about undeclared
functions, and things often work unless the return type is a
floating-point number or (on systems with ints and pointers of
different size) a pointer. It's a really bad idea to rely on it
though, because it may work on one system but not another, so
take note of compiler warnings!

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
 
Reply With Quote
 
Chris Torek
Guest
Posts: n/a
 
      01-15-2007
In article <(E-Mail Removed). com>
<(E-Mail Removed)> wrote:
>... i haven't included stdio.h and my compiler would generate a
>warning and would assume that it would return a int, my question is how
>does the linker manage to link the function invocation to the proper
>printf function?


Some have described the process by which particular specific linkers
happen to -- by "designed-in luck", as it were, although whether that
is "good luck" or "bad luck" is something of a matter of opinion --
make your call to printf() to a printf() routine in a library.

At least one person has noted that the behavior is officially
undefined.

There are some (rare) implementations on which the linker does
*not* manage to link your call to a library printf. So asking how
it did manage presupposes that you do not have such an implementation
-- it is a little like asking why sheep are white. (White sheep
are white for various reasons, but black sheep do exist.)

> and does including a header file having function prototype help the
>linker in any way?


It might. It might not. These things depend on the implementation.
Consider C++ for a moment, and note that C++ compilers commonly
use a technique called "name mangling", in which source-code function
names are replaced with link-time "mangled" names that encode the
*type* of the function as well as the original name. There is no
reason a C compiler could not do the same thing, so that:

int foo(void);
...
result = foo();

causes the linker to search for a name like i$foo$v. Including
stdio.h, which has to declare "printf" as having type int(const
char *,...) might tell the compiler to cause the linker to search
for i$printf$V.pc; but failure to include that header would leave
the compiler searching for i$printf$pc, so that the link would
fail.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
 
Reply With Quote
 
=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=
Guest
Posts: n/a
 
      01-15-2007
Chris Torek wrote:
> Consider C++ for a moment, and note that C++ compilers commonly
> use a technique called "name mangling", in which source-code function
> names are replaced with link-time "mangled" names that encode the
> *type* of the function as well as the original name. There is no
> reason a C compiler could not do the same thing, so that:
>
> int foo(void);
> ...
> result = foo();
>
> causes the linker to search for a name like i$foo$v. Including
> stdio.h, which has to declare "printf" as having type int(const
> char *,...) might tell the compiler to cause the linker to search
> for i$printf$V.pc; but failure to include that header would leave
> the compiler searching for i$printf$pc, so that the link would
> fail.


While name mangling is not prohibited, it is considerably more
difficult to implement in C, since function prototypes are not
required. There is nothing preventing a program from doing this:

a.c:
int (*get_puts(void))()
{
extern int puts();
return &puts;
}

b.c:
extern int (*get_puts(void))();
int main(void)
{
(*get_puts()) ((const char *) "Hello, world!");
}

When a.c is compiled, the compiler cannot know which types of arguments
puts expects. It may have special knowledge for the standard library
functions, but I could just as easily have used a user-defined function.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Maximize already running tkinter program on invocation Steven Kauffmann Python 2 07-27-2011 06:17 PM
Automated function call invocation diagram??? Peter Olcott C++ 5 08-17-2008 04:25 PM
access to the namespace of a function from within its invocation Poor Yorick Python 2 07-13-2007 03:03 PM
Having to "print" before method invocation? Jeremy L. Moles Python 0 03-08-2006 02:29 PM
Function invocation location 1.41421@gmail.com C Programming 15 12-23-2005 04:00 PM



Advertisments