warning: implicit declaration of function 'printf'

Johs32

I get this warning:

warning: incompatible implicit declaration of built-in function 'printf'

because I use printf in a function that I include in a .h file that is
included by other files...Do I need to remove the printf call?

Mar 30 '06 #1

Skarmander

Johs32 wrote:[color=blue]
> I get this warning:
>
> warning: incompatible implicit declaration of built-in function 'printf'
>
> because I use printf in a function that I include in a .h file that is
> included by other files...Do I need to remove the printf call?[/color]

No, you need to make sure <stdio.h> has been included before the point where
you invoke printf(), then fix any errors that result if the call is incorrect.

And if I'm reading you correctly, you're putting code in a header. Don't do
that. Headers should be used for declarations only.

S.

Mar 30 '06 #2

Walter Roberson

In article <442bd85f$0$11063$e4fe514c@news.xs4all.nl>,
Skarmander <invalid@dontmailme.com> wrote:[color=blue]
>And if I'm reading you correctly, you're putting code in a header. Don't do
>that. Headers should be used for declarations only.[/color]

That's a matter of style, not any restriction or recommendation of
the C language itself.

If one had a static function (i.e., file scope) that was used in several
places, I'm not sure that it would make much difference whether
one put the code into a file that was included where needed,
compared to if one put a #define of all of the code into a header
and then explicitly called upon the macro to define the function.
Using the macro version requires using continuation lines all
over the place, and would not allow for the possibility of
conditional compilation in the function definition.
--
"It is important to remember that when it comes to law, computers
never make copies, only human beings make copies. Computers are given
commands, not permission. Only people can be given permission."
-- Brad Templeton

Mar 30 '06 #3

Skarmander

Walter Roberson wrote:[color=blue]
> In article <442bd85f$0$11063$e4fe514c@news.xs4all.nl>,
> Skarmander <invalid@dontmailme.com> wrote:[color=green]
>> And if I'm reading you correctly, you're putting code in a header. Don't do
>> that. Headers should be used for declarations only.[/color]
>
> That's a matter of style, not any restriction or recommendation of
> the C language itself.
>[/color]
Of course. The phrase "don't do that" usually signals an opinion on style.
"You can't do that" would be a language restriction.
[color=blue]
> If one had a static function (i.e., file scope) that was used in several
> places, I'm not sure that it would make much difference whether
> one put the code into a file that was included where needed,
> compared to if one put a #define of all of the code into a header
> and then explicitly called upon the macro to define the function.
> Using the macro version requires using continuation lines all
> over the place, and would not allow for the possibility of
> conditional compilation in the function definition.[/color]

The first thing that springs to mind is that a function with file scope that
is used in several places is a contradiction in terms, but of course this is
not true; the odd situation is a consequence of C's approach to modularity
being restricted to files. One could have a library where externally visible
functions in different files needed to call a function that should not be
externally visible.

I'd argue that linkers are supposed to solve this problem, even if "linking"
is not part of the C language. One benefit to a solution through a linker is
that there really is only one function, not one function copied many times.
(This discussion is orthogonal to inline functions, which can also be
implemented by putting code in headers, and also have alternate approaches.)

But assuming linker magic isn't a solution, I do agree that #including the
function definition is cleaner than using a macro. I don't think that using
a macro is better just because it's supposed to get around the "don't put
code in a header" recommendation. The point of that recommendation is to
encourage people to have a clean split between interfaces and
implementations. You can do that even when you put code in a header, if you
know what you're doing.

It's comparable to "don't use goto". There will be circumstances where the
most appropriate course of action is to use goto, but if you can recognize
them you don't need the recommendation. All that is intended is to
discourage people from doing it arbitrarily.

S.

Mar 30 '06 #4

Mark McIntyre

On Thu, 30 Mar 2006 13:27:41 +0000 (UTC), in comp.lang.c ,
roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson) wrote:
[color=blue]
>In article <442bd85f$0$11063$e4fe514c@news.xs4all.nl>,
>Skarmander <invalid@dontmailme.com> wrote:[color=green]
>>And if I'm reading you correctly, you're putting code in a header. Don't do
>>that. Headers should be used for declarations only.[/color]
>
>That's a matter of style, not any restriction or recommendation of
>the C language itself.[/color]

Not entirely. If you put functions in a header, you get multiple
definitions. Plus it makes it even harder to find functions.
[color=blue]
>If one had a static function (i.e., file scope) that was used in several
>places, I'm not sure that it would make much difference whether
>one put the code into a file that was included where needed,[/color]

If you have a function you need in several files, its by definition
not a static, and shouldn't be declared as such. You're just bloating
your code. Put a declation in the header and a body in a source file.


Mark McIntyre
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

Mar 30 '06 #5

Stephen Sprunk

"Mark McIntyre" <markmcintyre@spamcop.net> wrote in message
news:svho22tidqmp9t0g3bo2sm463gupd3nfu8@4ax.com...[color=blue]
> On Thu, 30 Mar 2006 13:27:41 +0000 (UTC), in comp.lang.c ,
> roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson) wrote:
>[color=green]
>>In article <442bd85f$0$11063$e4fe514c@news.xs4all.nl>,
>>Skarmander <invalid@dontmailme.com> wrote:[color=darkred]
>>>And if I'm reading you correctly, you're putting code in a header. Don't
>>>do
>>>that. Headers should be used for declarations only.[/color]
>>
>>That's a matter of style, not any restriction or recommendation of
>>the C language itself.[/color]
>
> Not entirely. If you put functions in a header, you get multiple
> definitions. Plus it makes it even harder to find functions.[/color]

Harder to find? When I want to know where a function is, I grep *.h to find
it; it's usually clear from that output if it's defined or declared in the
header. If it's merely declared in the headers, then (depending on the
coding conventions) I may need to look through dozens of .c files to find
the definition.

Still, I would agree with the general "should not" as long as people
recognize that does not equate to "must not", similar to the near-ban on
gotos.
[color=blue][color=green]
>>If one had a static function (i.e., file scope) that was used in several
>>places, I'm not sure that it would make much difference whether
>>one put the code into a file that was included where needed,[/color]
>
> If you have a function you need in several files, its by definition
> not a static, and shouldn't be declared as such. You're just bloating
> your code. Put a declation in the header and a body in a source file.[/color]

Unless the function is declared inline, in which case it's duplicated
everywhere it's used anyway (possibly optimized differently in each case).
The compiler may be inlining your functions anyways without being told to,
depending on the optimization level.

I frequently use static inline functions in headers to replace macros to
avoid multiple-evaluation and type bugs (and I just don't like macros in
general). The gcc-ism of extern inline functions is even better in some
cases, if you have that extension available.

S

--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin

*** Free account sponsored by SecureIX.com ***
*** Encrypt your Internet usage with a free VPN account from http://www.SecureIX.com ***

Mar 31 '06 #6

Mark McIntyre

On Thu, 30 Mar 2006 21:24:31 -0600, in comp.lang.c , "Stephen Sprunk"
<stephen@sprunk.org> wrote:
[color=blue]
>Harder to find? When I want to know where a function is, I grep *.h to find[/color]

Great. Please feel to apply that idea to a many MLOC project split
into dozens of subdirectories, on a non-Unix platform... .
:-)
[color=blue]
>Still, I would agree with the general "should not" as long as people[/color]
Mark McIntyre
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

Mar 31 '06 #7