------- Comment #7 from andreagrassi at sogeasoft dot com 2007-08-29 13:56
-------
Subject: R: Error in compiling when there is a function with a char parameter
called before its declaration with inline parameters.
Thank you so much for the speed, the kindness and the precision with which
you answered me
but I continue to think this is a gcc programmers mistake or , at least, it
shouldn't work so.
1. First, you spoke about an internal difference between the "inline" and
"not inline" definition, but
in my opinion this should be only a syntax difference and not a semanthics
one.
In other words my two codes should be only formally different but with the
same meaning.
2. Then, I understand that the compiler at the compile-time must understand
the type of a value
and so it promotes this value to the larger type it can include this value
but then it should be
able to re-cast the type to the new type in the definition if there is
compatibility
between the two types. (In this case between "int" and "char" there is full
compatibility !!)
I know that re-casting an "int" to "char" I could have loss or alteration of
data because it pass from a larger to a smaller one but usually the C
permits this.
-You can think to the assignemt. The following code is allowed:
char c;
int i=0;
c=i; // <--- implicit conversion from larger to smaller!!!
Syntactically good code
-The pointer are accepted even if they belong to different type pointers.
This following code is syntactically permited even if it's full of type
errors that probably
will make my code fail !!
main()
{
double a;
ffa(&a); // <---- *double
} // |
// |
ffa(int *par) // <---- *int
{
char c;
printf("%c\n",*par); // char <--> int
return(0);
}
- ecc...
So a warning is correct (more, needed ) but not an error !!!
3. In the prevoius version (3.x) of gcc this was OK.!!
4. Consider the error message:
"an argument type that has a default promotion can't match an empty
parameter name list declaration"
empty parameter ? Where it saw this ? The message is wrong ...
This make me suspect that the compiler goes in an not managed case of
failure !!
In fact if I read your "c-decl.c" code in the function
"diagnose_mismatched_decls()",
the message "conflicting types for..." is the LAST branch of the
"if/then/elsif/../elsif/else" case !!
And the following line with "diagnose_arglist_conflict()" find a wrong
message/note because
probably this failure was not desired and considered.
Sorry if I bored with this long mail, but I try to explain to you the reason
for which I think this should be considered a bug. I know the problem is
by-passable
but I have a lot of sources with this new errors and this would make me to
adjust all these codes.
Please let me know if this can be considered a bug and if / when you think
to solve and fix it.
Thank you so much anyway.
Best regards.
Andrea
> -----Messaggio originale-----
> Da: raeburn at raeburn dot org [mailto:[EMAIL PROTECTED]
> Inviato: mercoledì 29 agosto 2007 13.13
> 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 #6 from raeburn at raeburn dot org
> 2007-08-29 11:12 -------
> (In reply to comment #5)
> > I don't understand the error !! It's all so simple and I
> don't understand
> > why the compile works if I write in the second form (not
> inline parameter
> > declaration) !!!
>
> (This would be more suitable for the gcc-help list, btw...)
>
> The bit about a type with default promotions refers to the
> fact that if there
> isn't a prototype declaration (or a prototype style function
> definition) in
> scope for the function, then integral arguments narrower than
> "int" get
> "promoted" to "int" in the function signature, and that's how
> the argument gets
> passed. (And "float" would become "double" as well.) Your
> second ("not
> inline") version uses a non-prototype style definition, so
> the passed argument
> type is in fact an "int".
>
> In the first version of your code, the function is called
> with no declaration
> in scope, so it's assumed that all argument types are the
> result of the default
> promotions, and then you declare it as taking a "char" not
> promoted to "int",
> which conflicts with the previous assumption.
>
> (The use of a function without a prototype in scope also
> causes the compiler to
> assume that it takes a fixed number of arguments, not a
> variable number of
> arguments like printf; gcc knows that printf takes a variable
> number of
> arguments, but warns you about it because according to the
> semantics of the C
> language, your source file is still requiring that printf be a
> non-variable-argument function. While on many platforms that
> won't cause you
> problems, on some it will; sometimes variable argument lists
> get passed
> differently from fixed argument lists.)
>
> I know it seems a bit odd; I think it's come to be this way
> mostly because of a
> combination of factors in the standardization process, mainly
> trying to allow
> really old C code (from before there was a language standard
> in 1989) to work
> as it was, and to allow compilers to get good performance out
> of modern code
> (using prototypes and such introduced with the 1989 standard).
>
> In short, if you want to use non-promoted types in your
> argument lists, you
> should make sure you've got prototypes in scope before the
> function gets
> referenced. Stick "int a(char);" at the top of the first
> version and it should
> work fine.
>
>
> --
>
>
> 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.
>
>
>
>
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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33219
