This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c/33219] Error in compiling when there is a function with a char parameter called before its declaration with inline parameters.



------- 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:gcc-bugzilla@gcc.gnu.org]
> Inviato: venerdì 31 agosto 2007 6.42
> A: andreagrassi@sogeasoft.com
> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]