------- Comment #15 from andreagrassi at sogeasoft dot com 2007-08-31 08:57 ------- Subject: R: Error in compiling when there is a function with a char parameter called before its declaration with inline parameters.
Thank you again Bye and good work. Le informazioni contenute in questo messaggio di posta elettronica sono di natura confidenziale; qualsiasi pubblicazione, utilizzo o diffusione anche parziale dello stesso non può essere effettuata senza autorizzazione e potrebbe costituire un illecito penale ai sensi del Decreto Legs.vo N° 196/2003 sulla Protezione dei Dati Personali e del Codice Penale, Art. 617-621-635 bis oltre che della legge 547/93. Qualora non siate tra i legittimi destinatari di questa e-mail Vi preghiamo cortesemente di cancellarla dal Vostro sistema dopo aver notificato al mittente, rispondendo alla comunicazione, l'errore da questi commesso. > -----Messaggio originale----- > Da: raeburn at raeburn dot org [mailto:[EMAIL PROTECTED] > Inviato: venerdì 31 agosto 2007 6.42 > A: [EMAIL PROTECTED] > Oggetto: [Bug c/33219] Error in compiling when there is a > function with > a char parameter called before its declaration with inline parameters. > > > > > ------- 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 > > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. > > > > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33219