This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Build: 201210100934 (Same result in NB 7.3 Beta 2 Build 201211062253) NB refactoring support renames a macro to another with the same name, leading to a behavioral change of the code. Reproducible: Always Steps to Reproduce: 1. Create a C file with the following code: #include <stdio.h> #define MACRO1 10 #define MACRO2 20 int main(){ printf("%d", MACRO1); return 0; } output: 10 2. Apply the rename refactor to the MACRO2 to MACRO1, and NB silently refactor #define MACRO1 10 #define MACRO1 20 //refactored from MACRO2 to MACRO1 int main(){ printf("%d", MACRO1); return 0; } 3. Behavioral change. New output: 20
Although this issue and that one (http://netbeans.org/bugzilla/show_bug.cgi?id=223898) look similar, the behavior is different. In this one, NB silently change the macro name to an existent, and the program compiles (as expected) and shows different value as output. The 223898 issue does not compile at all, since its a function with the same name. Look that this one (223942) is more dangerous, since the transformation NB does leads to a completely different output, . (Maybe solving one issue solve the other, but I dont know) What I am trying to say is that function and macro are different constructions in C, as can been seen in different behaviors of the related issues.
(In reply to comment #1) > Although this issue and that one > (http://netbeans.org/bugzilla/show_bug.cgi?id=223898) look similar, the > behavior is different. In this one, NB silently change the macro name to an > existent, and the program compiles (as expected) and shows different value as > output. The 223898 issue does not compile at all, since its a function with the > same name. Look that this one (223942) is more dangerous, since the > transformation NB does leads to a completely different output, . (Maybe solving > one issue solve the other, but I dont know) > > What I am trying to say is that function and macro are different constructions > in C, as can been seen in different behaviors of the related issues. I understand your point and do not question its validity. However this opens up a door for hundreds of bugs. You may want to check what if you have a function f1() and and a macro F1() and occasionally rename f1 to F1. I bet you'll be disappointed, but there is no point to track all these similar issues under so many bugs. The point is taken - the name collision must be checked and user must be warned. Do you see a value in finer granularity of the issues?
I still think this case has to be independent to the other given they have different behavior, and because macro is different of function. Eclipse CDT, for example, has different approaches. To show that, look the attached image: rename macro in CDT (newest version). > However this opens up a door for hundreds of bugs I dont think so, since any macro rename bug (renaming to another with the same name) is just one bug, and any function rename bug (renaming to another with the same name) is just one bug. So, just two ;). If you allow, I will reopen this case to reconsideration. Ok? Thank you Leonid.
Created attachment 129477 [details] Eclipse behavior after a macro rename to a name of an existent one