warning: implicit declaration of function 'printf'

J

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?
 
S

Skarmander

Johs32 said:
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?

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.
 
W

Walter Roberson

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.

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.
 
S

Skarmander

Walter said:
That's a matter of style, not any restriction or recommendation of
the C language itself.
Of course. The phrase "don't do that" usually signals an opinion on style.
"You can't do that" would be a language restriction.
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.

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.
 
M

Mark McIntyre

On Thu, 30 Mar 2006 13:27:41 +0000 (UTC), in comp.lang.c ,
That's a matter of style, not any restriction or recommendation of
the C language itself.

Not entirely. If you put functions in a header, you get multiple
definitions. Plus it makes it even harder to find functions.
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,

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
 
S

Stephen Sprunk

Mark McIntyre said:
On Thu, 30 Mar 2006 13:27:41 +0000 (UTC), in comp.lang.c ,


Not entirely. If you put functions in a header, you get multiple
definitions. Plus it makes it even harder to find functions.

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.
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.

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 ***
 
M

Mark McIntyre

Harder to find? When I want to know where a function is, I grep *.h to find

Great. Please feel to apply that idea to a many MLOC project split
into dozens of subdirectories, on a non-Unix platform... .
:)
Still, I would agree with the general "should not" as long as people
Mark McIntyre
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top