------- Comment #14 from raeburn at raeburn dot org 2007-08-31 04:42 ------- Subject: Re: Error in compiling when there is a function with a char parameter called before its declaration with inline parameters.
On Aug 30, 2007, at 3:55, andreagrassi at sogeasoft dot com wrote: > A last thing if you can explain me: > > Why the compiler report an error in my code, whereas if a modify my > invalid > code splitting the "main()" and the "a()" functions into different > sources > and the I compile even no warnings !! Why the compiler is so strict (1 > error ) and the linker so permissive (0 warnings) ? > If the signature was different even the linker should report an > error . In C, there just isn't enough information preserved in the object files for the linker to do such a check. For the most part, the object file just has symbol names, executable machine code, and data, without a description of what the data structures are, or what types of arguments are required by the functions. If you compile with debugging flags, some of the information is still there in the file where the function is defined, so the debugger can show you the function's arguments. But the file where the call is made doesn't generally record information about what sort of arguments it expects the function to take, to the best of my recollection. So even if the linker parsed the debugging info, it still wouldn't be able to detect this inconsistency. In terms of the language specification, the program is incorrect, but the compiler is not required to detect the problem in this case, even if it can't give you a program that works. Yes, in some cases this really gives a lot of latitude to the compiler writer, and makes it hard on the application writer. Whether or not the compiler detects problems that it's not required to is called a "quality of implementation" issue. While gcc can't detect this particular problem you describe above at compile time or link time, it does have some warning options that can help you. For example, you can have it warn you if you call a function that you haven't declared first. Combine that with a practice of declaring any function only once in a program, in a header file included everywhere you use the function and where you define it, and it ensures that you have consistent declarations for your functions. It might be theoretically possible to have the compiler write some additional information into the object files, and change the linker look for that information. But as the object file format and the linker implementation are very system-specific, parts of it would have to be implemented over and over for different kinds of systems. And while the GNU project does have a linker available in the binutils package, it doesn't support all systems, so even once it's done, it would still only get you the warnings you want on some systems and not on others. I won't say no one's going to tackle such a project, but personally I doubt it's going to be a high priority for many people, especially given that coding practices like I described above can take care of most cases of this kind of problem. Ken -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33219
