Path: utzoo!telly!attcan!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!lll-winken!uwm.edu!cs.utexas.edu!tut.cis.ohio-state.edu!CSRI.TORONTO.EDU!moraes
From: moraes@CSRI.TORONTO.EDU (Mark Moraes)
Newsgroups: gnu.gcc
Subject: Re: Software tool (indent) munges code
Message-ID: <89Dec12.214540est.935@church.csri.toronto.edu>
Date: 13 Dec 89 02:45:30 GMT
Sender: daemon@tut.cis.ohio-state.edu
Distribution: gnu
Organization: GNUs Not Usenet
Lines: 46

In RISKS-9.50, lai@east.Berkeley.EDU (Nick Lai) comments that indent
has an insidious bug under BSD and SunOS. He is wrong about the bug
under BSD and SunOS, right about the bug if his compiler is ANSI
compliant, but definitely right in pointing out the risk.

- On Unix systems, pcc derived C compilers will interpret that code
exactly as indent did, generating a warning in the process, so indent's
behaviour would not change the intent of the code. (Like the
compilers, indent should probably warn the user) Therefore, for old
style C, indent's behaviour is NOT wrong. Most old compilers would
have treated that code the way indent did, so indent just made the
code clearer.

- With ANSI C compilers, the =op style syntax is obsolete. This is one
of the QUIET CHANGEs in the proposed ANSI C standard -- see section
3.1.5 (Operators) of the Rationale (my copy is dated Oct 31,1988 -- the
section number may have changed since)

So, if the programmer wrote
        x=+1;

ANSI C compilers would interpret this to mean "assign the
value +1 to x". (GNU C version 1.34 on a Sun3 interprets it this way
*EVEN* with the -traditional flag)

K&R1 C compilers would interpret this to mean "increment x by 1"
pcc derived compilers also complain with something like:
"foo1.c", line 7: warning: old-fashioned assignment operator
"foo1.c", line 9: warning: ambiguous assignment: assignment op taken
I don't know if other K&R1 compilers complain this way.
(Note that Ultrix 3.1 compilers also follow K&R1 and complain)

indent as distributed with BSD and SunOS silently assumes K&R1 C behaviour
and converts it to
        x += 1;

GNU indent version 1.1 assumes ANSI C behaviour and converts it to
        x = +1;
Ultrix 3.1 indent does this too (even though their compiler still
follows K&R1!)

People converting programs from old C to ANSI C should check all code
(using grep or some similar tool) to make sure sequences of the form
"=op" are converted to "= op" or "op=" depending which is meant! (And
make some suggestions on programming style to the person who wrote the
code originally)