GCC how to stop false positive warning implicit-function-declaration for functions in ROM?

4
votes

I want to get rid of all implicit-function-declaration warnings in my codebase. But there is a problem because some functions are programmed into the microcontroller ROM at the factory and during linking a linker script provides only the function address. These functions are called by code in the SDK.

During compilation gcc of course emits the warning implicit-function-declaration. How can I get rid of this warning?

To be clear I understand why the warning is there and what does it mean. But in this particular case the developers of SDK guarantee that the code will work with implicit rules (i.e. implicit function takes only ints and returns an int). So this warning is a false positive.

This is gnu-C-99 only, no c++.

Ideas:

  • Guess the argument types, write a prototype in a header and include that?
  • Tell gcc to treat such functions as false positive with some gcc attribute?
6
cgccmicrocontroller
Is this C code or C++? Are namespaces involved? - wallyk
Have you tried adding -Wno-implicit-function-declaration to your cflags? - Stephen Newell
@StephenNewell I want to resolve the false warnings, not ignore them. Because I dont want to miss the real warnings. - user10607
You can put a function declaration int name(); for each one. Don't put a prototype. - M.M
You forgot to post the exact example code that produces these error messages. - Roland Illig

6 Answers

4
votes

You can either create a prototype function in a header, or suppress the warnings with the following:

#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wimplicit-function-declaration"
/* line where GCC complains about implicit function declaration */
#pragma GCC diagnostic pop
1
votes

Write a small program that generates a header file romfunctions.h from the linker script, with a line like this

int rom_function();

for each symbol defined by the ROM. Run this program from your Makefiles. Change all of the files that use these functions to include romfunctions.h. This way, if the linker script changes, you don't have to update the header file by hand.

1
votes

Because most of my programming expertise was acquired by self-study, I intentionally have become somewhat anal about resolving non-fatal warnings, specifically to avoid picking up bad coding habits. But, this has revealed to me that such bad coding habits are quite common, even from formally trained programmers. In particular, for someone like me who is also anal about NOT using MS Windows, my self-study of so-called platform-independent code such as OpenGL and Vulkan has revealed a WORLD of bad coding habits, particularly as I examine code written assuming the student was using Visual Studio and a Windows C/C++ compiler.

Recently, I encountered NUMEROUS non-fatal warnings as I designed an Ubuntu Qt Console implementation of an online example of how to use SPIR-V shaders with OpenGL. I finally threw in the towel and added the following lines to my qmake .PRO file to get rid of the non-fatal-warnings (after, first, studying each one and convincing myself it could be safely ignored) :

QMAKE_CFLAGS += -Wno-implicit-function-declaration
-Wno-address-of-packed-member

0
votes

[Completely written due to commends]

You are compiling the vendor SDK with your own code. This is not typically what you want to do.

What you do is you build their SDK files with gcc -c -Wno-implicit-function-declaration and and your own files with gcc -c or possibly gcc -o output all-your-c-files all-their-o-files.

0
votes

C does not require that declarations be prototypes, so you can get rid of the problem (which should be a hard error, not a warning, since implicit declarations are not valid C) by using a non-prototype declaration, which requires only knowing the return type. For example:

int foo();

Since "implicit declarations" were historically treated as returning int, you can simply use int for all of them.

-2
votes

If you are using C program, use

#include <stdio.h>