the compiler will not let me declare an __stdcall__ pointer to function member and code will than SEGFAULT on invocation of the member pointer. This is not the case for Regular pointers to functions. ( The compiler will also issue a warning on mismatch.) Listing of the Error: (BAD) class AFoo { public: __attribute__((__stdcall__)) void foo(int i ,int ii ,int iii) ; } ; __attribute__((__stdcall__)) void AFoo::foo(int i ,int ii ,int iii) { return ; } int main() { AFoo afoo ; void ( AFoo::*func)(int,int,int) ; func = &AFoo::foo ; for(int i=0 ; i < 0x8000000 ;i++) (afoo.*func)(1,2,3) ; // SEGFAULT or SEGIL when stack is Exhausted return 0 ; } any attempt to place the __atribute__((stdcall)) in the pointer declaration causes a compilation error. With out it the code will SEGFAULT. If declaring a regular pointer to function than no compilation error is issued and all is well. Listing of Regular function pointer: (GOOD) void __attribute__((stdcall)) foo(int i ,int ii ,int iii) { } int main() { void ( __attribute__((stdcall)) *func)(int,int,int) = &foo ; for(int i=0 ; i < 0x8000000 ;i++) (func)(1,2,3) ; return 0 ; } removing the __attribute__((stdcall)) from the *func declaration will rightfully issue a warning ( should be an error if you ask me, type mismatch). But Not so on our first example.
This is a dup of bug 4507 which still exists on the mainline and 3.3. *** This bug has been marked as a duplicate of 4507 ***
Not true. It is not at all the same bug and this one has no work around. !!!! I have seen bug #4507. As you can see this bug exposes a situation where an __stdcall__ implementation is called by a none __stdcall__ pointer hence causing a SEGFAULT. the Error is not in the code generation of the __stdcall member function, that one is implemented correctly. The bug is in not able to define an __stdcall pointer to a function-member and in allowing an assignment of __stdcall __ function to a none __stdcall__ pointer. Please return the bug. Note that it is marked "critical" since it breaks (with no way to work a round it) use of COM technology on Linux. (Wine project)
I can confirm this on the mainline (20030812), the problem is that GCC is ignoring it on member types of functions.
Note critical severity is only for use by the GCC developers for regressions since this has been a problem since 2.95.3 this is not a regression.
Sorry to be picky, but wrong again. The problem is that GCC will not let me define an stdcall pointer to member-function. The bad line above is: void ( AFoo:*func )(int,int,int) ; // BAD it should be: void ( __attribute((stdcall)) AFoo:*func )(int,int,int) ; // GOOD but ... but this line produces an error where it shouldn't. And Also: func = &AFoo::foo This line should produce an error (type mismatch) where it is bypassed unsuspectedly Note the good syntax when none member are used (in the second example above)
On the mainline, the one you say got rejected no longer gets rejected but it is ignored and still produces the segfault so I was not totally wrong, just wrong for released version.
I have found a nice Work around that also introduces a very good code practice Here is the code: < c++ code > #define __stdcall __attribute__((__stdcall__)) class AFoo { public: __stdcall void foo(int i ,int ii ,int iii) ; } ; __stdcall void AFoo::foo(int i ,int ii ,int iii) { return ; } int main() { AFoo afoo ; // now here is the nice thing Note the use of typeof() operator typedef typeof(&AFoo::foo) Afoo_func ; Afoo_func func = &AFoo::foo ; for(int i=0 ; i < 0x8000000 ;i++) (afoo.*func )(1,2,3) ; // the code gets to be right this time return 0 ; } < c++ code/> Well there it is. I am not sure how to make existing (Windows) code compile but new code can use this syntax to have pointers to __stdcall member functions work right. (I think that the fact this works shows that the problem is in the parser and not the Generating of code.) I like this syntax better than the classical one because, in evolving code, typedef of functions-pointers do not have to change, when a decision is made to change the functions prototype. I hope this is any help Free Life Boaz
This is a dup of bug 9381. *** This bug has been marked as a duplicate of 9381 ***
*** Bug 260998 has been marked as a duplicate of this bug. *** Seen from the domain http://volichat.com Page where seen: http://volichat.com/adult-chat-rooms Marked for reference. Resolved as fixed @bugzilla.