--- Additional Comments From SebastianR at gmx dot de 2005-07-04 01:38
---
I think there might be an actual bug with this new warning:
In the qsort man page, it says you can use strcmp as the last argument to qsort.
So the types must be compatible, and it also works. However, this fails:
--- Additional Comments From manus at eiffel dot com 2004-11-11 20:04
---
Sorry to come back and buzz you again. I just realized that because of this
change in behavior of gcc you broke not just my code, but also the code of the
people using our Eiffel compiler. Indeed our compiler gen
--- Additional Comments From joseph at codesourcery dot com 2004-11-10
01:41 ---
Subject: Re: Warning not legitimate
On Wed, 10 Nov 2004, manus at eiffel dot com wrote:
> I believe we do not have the right definition of unspecified behavior. Going
We're talking about undefined behav
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-10
01:26 ---
extern void f();
really means
extern void f(...);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18411
--- Additional Comments From manus at eiffel dot com 2004-11-10 01:24
---
I believe we do not have the right definition of unspecified behavior. Going
back to my initial post:
extern void f();
void g(char a) {
((void (*) (char)) f)(a);
}
Knowing that actually `f' has been declared
--- Additional Comments From joseph at codesourcery dot com 2004-11-10
01:15 ---
Subject: Re: Warning not legitimate
On Wed, 10 Nov 2004, manus at eiffel dot com wrote:
> Ok, so why don't you generate the warning only when it makes sense. In my
> original case, I was passing a char a
--- Additional Comments From manus at eiffel dot com 2004-11-10 00:59
---
Ok, so why don't you generate the warning only when it makes sense. In my
original case, I was passing a char and tell the C compiler it was a function
pointer expecting a char. In this scenario it should not pro
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-10
00:47 ---
We cannot do 1 as that is not allowed by the C standard (or at least a DR
report of it). Also the reason
why this was changed was because the tree inliner was crashing on things like
this if the type was
--- Additional Comments From manus at eiffel dot com 2004-11-10 00:42
---
Thanks for your answer. I see that following the ANSI C standard forces you to
do something. But I believe the right thing to do is:
1 - make it a compile time error (better to catch those errors at compile time
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-09
23:51 ---
As said before this is undefined code.
--
What|Removed |Added
Status|UNCONFIRMED
--- Additional Comments From joseph at codesourcery dot com 2004-11-09
23:47 ---
Subject: Re: Warning not legitimate
On Tue, 9 Nov 2004, manus at eiffel dot com wrote:
> extern void f();
>
> void g(int a) {
> void * fnptr = f;
>
> ((void (*) (int)) fnptr) (a); /* Ok. */
--- Additional Comments From manus at eiffel dot com 2004-11-09 23:34
---
Also one thing I forgot to add. Is that if you replace `char' by `int' then
there is no warning at all:
extern void f();
void g(int a) {
void * fnptr = f;
((void (*) (int)) fnptr) (a); /* Ok. */
--- Additional Comments From manus at eiffel dot com 2004-11-09 23:32
---
This is not undefined, I know which feature I'm calling. It is `f'. Moreover I
provide the right function cast which matches how `f' is actually declared.
What strikes me the most is that you reject:
((void (*)
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-09
23:29 ---
The warning is correct:
extern void f();
void g(void)
{
((void (*) (char)) f)(a);
}
this is undefined code which means we could anything at runtime (even wipe out
your HD).
--
What|Remo
14 matches
Mail list logo
