Bug: Switch statement's dot graph is missing some parts
transfer xml into specific text-formats (html, dot, source-code, ...)
Brought to you by:
eckard_klotz
Menu
▾
▴
Input:
main() {
switch (getchar()) {
puts("begin");
case 'a': {
puts("case a");
}
case 'b': {
puts("case b");
}
}
}
Result:
puts("begin") is missing in output dot script
Hello Mr. Nelson.
From my point of view this should be ok for C/C++. Until now I have always learned that commands inside a switch but not placed as a part of a case or default will be ignored.
Never the less I tried it out. The attached zip-file contains some extracts of my experiment.
The c-file contains 3 functions. While the first one contains your original example the other two are modified. I have replaced your puts-command by printf to ensure a shell-output and in the last example I added a break behind every case.
The xml-file contains the associated result of the parser-tool abc2xml. Please note that I use for user-examples a bigger source that contains some more code and this results in line-numbers starting behind 750. Here you can see that the compound_statement of the switch_stmt contain the additional expr_stmt even it will not be used. This means that the parser is not disturbed.
The dt-files are the dot-scripts. As mentioned above they contain inside the switch_stmt only parts associated with the case_stmt parts.
The gif-files show the result-diagrams. Note that it makes a difference if you use a break or not since the behavior of c/c++ differs here.
Please take a look and post your doubts or further clarifications.
Best regards,
Eckard Klotz
Commands inside a switch but not placed as a part of a case or default will not always be ignored.
Look at this case:
main() {
switch (getchar()) {
lbl:puts("begin");
goto cont;
case 'a': {
goto lbl;
cont: puts("case a");
}
case 'b': {
puts("case b");
}
}
}
Obviously puts("begin") doesn't ignored by C/C++ but still missing in result dot-script.
The attached zip-file contains test case with its .dt and .gif outputs.
One more test case.
Hello Mr. Nelson
There is a good reason why they recommend in today's software design lessons to avoid the using of goto. Please don't take me wrong, if I see that your two attached examples show why.
Before I start to think about implement your request or to keep the current behavior, lets discuss if I understood your examples. Therefor I attached two diagrams where I tried to do manually to what Moritz is currently not able to do for you automatically.
If you now take a look two my manually created diagrams and they are right you will see why your implementation is problematic:
examples switch_goto (diagram main_SwitchGoto1)
Since you label is placed over the first case i would assume that you will get an endless loop since the case below jumps always back to the begin.
examples switch_goto2 (diagram main_SwitchGoto2)
Since you placed a second goto command at the end to your first label sequence, that jumps back into your case, to continue its command sequence, it would be the same as moving your label action into the case-sequence and to remove all goto-commands and labels.
Please check if the two diagrams show the algorithm you have implemented in you attache examples switch_goto and switch_goto2.
Even your used compiler may create a binary that behaves like you wish, please ensure that this behavior is really specified for standard C/C++ and not only a specific solution of your used compiler, since there is no common C/C++ specification for your construction.
I'm sure you have good reasons for your implementation. But by using goto you are able to implement really mind blowing solutions. For example you are able to jump somewhere into an other functions, what is not supported by Moritz also. When I studied, my teachers called that spaghetti code. Since the intelligence of the generator binary xml2abc is limited, I'm not able to define one general solution and the analysis of goto commands will be always limited. Thus please tell me more about your idea behind. Than I will think about, if it is possible to support you and to discuss how. Until that I would define your observation as a wanted limitation.
Best regards,
Eckard Klotz