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?
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
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.
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
[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.
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.
If you are using C program, use
#include <stdio.h>
I just installed gmp from https://gmplib.org/, on my MacBook, which I'm completely new to. (I'm quite new to C and mpi as well for that matter.)
Now I have a C code containing both the headers mpi.h and gmp.h. If I try to compile the code with mpicc, as I usually do when not using gmp, it complains about not finding 'gmp.h'. On the other hand, if I compile with gcc it complains about not finding 'mpi.h'. So, what should I do to be able to compile my code?
I need both the headers since I will need to work with huge numbers in a parallel environment. I.e. removing any one of them is really not an option.
I'm thankful for any help with this issue.
I'm attempting to write a C program incorporating OPENFILENAME and of course I need the header file. So, following the instructions provided with tcc, I downloaded the header files MinGW uses for the Win32 API (and the library files) and put them in the appropriate directories as instructed. However, when I come to compile the program, I get the following error:
In file included from sw1.c:2:
c:/prg/tcc/include/winapi/commdlg.h:503: declaration list expected
This seems rather odd, given it's a standard header. So, I look up the line and it's typedef __AW(CHOOSECOLOR) CHOOSECOLOR,*LPCHOOSECOLOR;, which doesn't look very valid to me but then I'm not really a C expert and I've mainly been writing in Linux. I have no idea why it's going wrong though and no knowledge of how to fix it? Is it a bug in tcc?
As evidence that this should be possible, here is the appropriate passage from the tcc readme:
Header Files:
The system header files (except _mingw.h) are from the MinGW
distribution:
http://www.mingw.org/
From the windows headers, only a minimal set is included. If you need
more, get MinGW's "w32api" package.
I understand that this question is similar to Error when including Windows.h with TCC but my "windows.h" file does work - it's just this that doesn't.
Does anyone know how to solve this? I'm really at a loose end!
I've recently migrated from Windows 7 to Linux (Ubuntu 14.04) and want to compile a C program that I made. The program worked perfectly under Codeblocks 12.11 using GNU GCC compiler's basic settings. When compiling under linux under Codeblocks 13.12 using GNU GCC compiler's basic settings, I get the following error messages:
undefined reference to __mingw_vprintf
undefined reference to __chstk.ms
undefined reference to _fopen
... and so on with fscanf, malloc, etc...
I'm new to Linux and I am not used to C coding, or even programming in general. Does someone have an idea about what's going on?
you have three separate problem going on here.
(1) for _fopen, Microsoft has a nasty habit of renaming all the POSIX functions so they start with an underscore, while your Linux distribution is looking for the standard POSIX name, i.e. fopen. Welcome to the wonderfully frustrating world of cross-platform development :). On solution would be to add something along these lines:
#ifdef __WIN32
#define fopen _fopen
#endif
This in effect says, if compiling on a windows machine (which typically has __WIN32 defined as a preprocessor define; and if it is not you can always make sure that it is) replace every occurrence of fopen with _fopen. The preprocessor will do this for you.
(2) for __mingw_vprintf, I've never seen this function but from the name I would surmise that it is an implementation of vprintf specific to mingw. I personally would rewrite my code to stick with the standard C function vprintf. You can read the manual page for vprintf here; and the MSDN information can be found here. Again notice that many of the Microsoft provide functions have an underscore prepended to the name. You can do something like what you did in case (1) above.
N.B. Actually if I were to rewrite the program I would use C++ IO-streams, but I am sticking to a pure C answers.
(3) for __chstk.ms, again I've never seen this function. My suspicion is that it is something inserted into your code to perform stack checking to help prevent stack-based exploits. To the best of my knowledge there is no way you are going to get that to work on a Linux machine.
I downloaded and compiled the header which is used in pthread functions. But one function is missing and that is *__lll_robust_lock_wait*. Now I noticed that there is an assembly code header out there, . I downloaded this and tried to compile it using the usual the compile command "as lowlevelrobustlock.S" and I got nearly 100 compiler errors. Is there a simpler version of the function I mentioned that will actually compile and be useful?
The assembly code header can be found here