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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.