Re: Bug with case labels
Lynn Kerby <[email protected]>
| Newsgroups | gmane.comp.gnu.indent.bugs |
|---|---|
| Message-ID | <[email protected]> |
[ FYI: moving my reply back on-list] On Sep 24, 2006, at 10:24 PM, Prakhar Deep wrote: > I believe the indentation done by -kr is one of the most followed > indentation format. So, i have no reason to drop out -kr from my > indentation options. Agreed. I didn't intend to suggest that using -kr is the problem, merely that the inconsistent formatting is triggered by the use of -kr. > If the some of the sub-option under the -kr is causing trouble i > expect a change in the -kr sub-options. Well, that would be reasonable *if* it can be demonstrated with a case that involves legal, parsable "C". With the preprocessor macros you have created a new variant of the language. I do consider the non-deterministic formatting you point out a bug in indent, but it is very low priority and unlikely to get much attention if it only happens with invalid input. >> However,.... >> I don't believe indent can or should handle this code as it is not >> technically legal C (or C++) IMO. I am assuming that PREFIX and >> SUFFIX are some preprocessor definitions that evaluate to legal >> statements, but indent is not aware of their expansions. If I add >> terminators to both PREFIX and SUFFIX, the output is constant >> (confused, but constant). > > You are correct PREFIX is actually: > > #define PREFIX break; > > and SUFFIX is a new line. > > If i replace the macros with their expansions then the indentation is > indeed constant. > > Can you suggest a set of options that we can use to stop this behavior > of indent? No, you have added the equivalent of reserved token with those preprocessor macros. As I mentioned, adding semi-colons after PREFIX and SUFFIX can resolve the problem of indent's non-deterministic behavior with this input. It has been my experience that declaring macros that include statement terminators is a bad practice. PS - I didn't catch it before, but "case2:" is being treated as a label. It could have been a typo, but if it is intended to be a 'case' for the switch then you must have a space before the 2. Lynn Kerby