Community
Participate
Working Groups
It will be nice to see eclipse automatically correcting the type casting issues...The compiler exactly reports the error with the type cast; the editor should provide auto correction option to fix these kind of issues...Right now it shows "no suggestions"... To be clear... char* string; string = malloc(); // This needs a type cast: string = (char *) malloc(); The editor should allow to automatically insert the type info...
Is it going to be fixed...priority 3???? Just try porting a C project to C++ and you will see importance of this...Not always the complex issues are high priority ones...
We are missing a piece of infrastructure to do verification on c/c++ code beyond what's necessary for indexing.
It is possible to rely on error parser markers to implement quick fixes. But I'd rather not encourage type casts that way.
(In reply to comment #3) > It is possible to rely on error parser markers to implement quick fixes. But > I'd rather not encourage type casts that way. Hmm, with error parsers it will be hard to deal with different compilers in different versions using different langugages. Also it will be non-trivial to find the correct spot for the correction. Also, it would be nice to have the quick-fixes available without the need to compile the code. Doing a parser based solution does not per se prevent the implementation of error-parser based quick-fixes, however it might be confusing to users to have two different paths to solve the same problem?
(In reply to comment #4) I agree that parser based solution is more attractive. Perhaps I underestimate easiness of implementing necessary infrastructure. There is still a niche for error parser quick fixes, for example we've implemented quick fixes for Flexelint warnings and for our own custom build system errors/warnings.
It should be appropriate to handle with codan, changing component.
I've opened bug 352071 for a more complete checker for casts and I'm working on it. I plan to add quick fixes (the case you mentioned and more) afterwards.
