------- Comment #13 from andreagrassi at sogeasoft dot com 2007-08-30 07:54 ------- Subject: R: Error in compiling when there is a function with a char parameter called before its declaration with inline parameters.
Ok, Ken, I understood. Thank you again for your detailed explanation. Your good manner of answering has been useful for me, unlike the 2 your colleagues... 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 . If the linker (that is the merger of the functions) is able to use this code merging the 2 functions with different signatures, I don't understand why the compiler should reject my code. Friendly, according to me, this remains not a real error, the compiler could be able to handle this case, don't you ? However, good work to you and all the gcc staff. Bye. Andrea 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: mercoledì 29 agosto 2007 23.51 > 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 #12 from raeburn at raeburn dot org > 2007-08-29 21:51 ------- > Subject: Re: Error in compiling when there is a function > with a char parameter > called before its declaration with inline parameters. > > On Aug 29, 2007, at 13:39, andreagrassi at sogeasoft dot com wrote: > > I accept the answer to gave me but then also the definition of > > > > a(a) > > char a; > > { > > ... > > > > should be invalid. I don't understand why if I define > > > > a(char a) > > { > > ... > > > > the compiler take a as "char" and don't match with promoted type > > giving me > > an error whereas the other way the compiler promotes the "char a" > > to "int" > > ALSO IN THE DEFINITION of the function !! > > It would seem to make sense, wouldn't it? But that's not how the C > standard was defined. It does cause confusion, but I guess the > benefit of letting "new-style" code be optimized better (e.g., you > can read a byte from memory and stuff it in the argument list, > without having to do the signed or unsigned widening to full "int", > or pass a "float" using 4 bytes on the stack instead of widening it > to an 8-byte "double") while leaving the meaning of "old-style" code > unchanged (old 1970s and 1980s compilers would always do the > "default > promotions", even if it slowed down the code a little) was deemed to > be worth it. I wasn't there, and can't read the minds of the people > on the committee, but it's a fait accompli at this point. > > Note too that in the 1999 version of the standard, the ability to > write the "old-style" code is described an "obsolescent > feature", and > the general direction the standards are moving in seems to suggest > that you should (1) always include a prototype declaration before > calling a function (or include the relevant header for standard C > functions), and (2) always use the prototype-style function > definitions instead of the older style. Having a prototype > declaration in scope before using a function is good practice, > anyways, because it lets the compiler do better type-checking > of your > function call, even if the function definition isn't in the same file. > > > Why in summary > > > > a(a) > > char a; // => promoted to int > > { > > ... > > > > whereas > > > > a(char a) // =>remains char > > { > > ... > > > > The two manner defines the SAME THING (even if in 2 different > > forms) and > > MUST be treated identically > > The C language specification says no, they're actually not > the same. > It causes some confusion when converting old C code to use prototype > declarations and definitions, because you might think you could just > move the argument declaration up without changing the semantics, but > it does change them subtly. > > > Then, finishing, I don't understand because you must promote a > > parameter > > EXPLICITLY rapresented by a char-constant as 'A' or by a variable > > previously > > declared as char, or why, once promoted, you cannot re-correct the > > signature > > !! The definition should override the implicitly signature . > > I know it's from always so, but this is a twist of the logic of the > > language. > > Actually, that's another funny point of C... and in fact it's > an area > where C and C++ are different. Character constants like 'A' are > actually considered to have type "int" in C, not type "char"! > I have > no idea what the logic was behind that (probably it's what 1970s-80s > compilers did), but once again, it was decided years ago and that's > the way it is. > > Go ahead and try something like > > printf("%d\n", sizeof('a')); > > ... the size isn't 1 in C, it's the size of an int. > > C++, on the other hand, treats 'A' as a "char" constant. It's > probably a lot more important to distinguish "char" from > "int" in C++ > where you might be doing function overloading or template > instantiation based on the type. > > 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
