eichelbe@nadc.arpa (J. Eichelberger) (11/10/87)
We are running 4.3 BSD UNIX on a VAX 11/780.
The following bug has been found when "indent" was run. No flags were
specified. Just "indent input.c output.c".
The input.c file looks like this:
main()
{
int i=0;
i=!i;
if(i) printf("true\n");
}
Unfortunately, the output.c file looks like this:
main()
{
int i = 0;
i != i;
if (i)
printf("true\n");
}
---
Notice the change in the line "i=!i;" to "i != i;". I know the workaround,
but input.c compiles and works. output.c compiles, too, and "works as
coded", but indent has corrupted the code.
If this bug has been fixed, please forward the bug fix to me.
Thank you.
Jon Eichelberger
eichelbe@NADC.ARPAchris@mimsy.UUCP (Chris Torek) (11/12/87)
In article <10266@brl-adm.ARPA> eichelbe@nadc.arpa (J. Eichelberger) writes: > i=!i; becomes > i != i; Sorry about that. This is a side effect of the `indent converts old style assignment operators' `feature'. I intend to remove this `feature' someday---perhaps at about the same time as 4BSD cc stops supporting it as well. There is an argument against this: if the compiler stops supporting it, perhaps indent should continue to support it so that one can translate old code mechanically. I think I am going to ignore this argument: most of said old code is in /usr/src, not in users' sources, at least per my own experience. Consider this a warning: The next BSD (apply usual disclaimers) will probably not support =<op> operators. That is, `i =+ 1' will not compile, though `i += 1' will. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
gwyn@brl-smoke.UUCP (11/12/87)
In article <9313@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >... That is, `i =+ 1' will not compile, though `i += 1' will. i =+ 1; should compile but be inequivalent to i += 1; the former should assign the value 1 to variable `i' while the latter should increment the contents of `i'.
clark@calma.UUCP (11/14/87)
In article <10266@brl-adm.ARPA> eichelbe@nadc.arpa (J. Eichelberger) writes: >We are running 4.3 BSD UNIX on a VAX 11/780. > >The following bug has been found when "indent" was run. No flags were >specified. Just "indent input.c output.c". (detailed description deleted >Notice the change in the line "i=!i;" to "i != i;". I know the workaround, (more deleted) > Jon Eichelberger > eichelbe@NADC.ARPA I am only speculating, but the "=!" to "!=" change may be a feature, not a bug. For example, the old form of "+=" and "-=" was "=+" and "=-". At least for some compilers, the older form is still honored, presumably in the name of backwards compatabil- ity. In those cases expressions like "a=-1" get treated as though they were "a-=1". I always leave a space between an equal sign and a following operator, just to be sure. It is interest- ing that indent, at least in this case, treated the "=!" just as the "backwards compatible" compiler would, but makes the in- terpretation obvious. So I would think of it as a feature, not a bug, in that it makes the output non-ambiguous. (In passing, note that the "=+" construct is still honored by all the versions of "bc" that I use, and is the only construct honored by the "bc" in my Unisoft sytem.) -- Al Clark - {ucbvax,sun,...}calma!clark ...calma!gewest!aclark!al NOTE: The calma account is a courtesy account; I am not employed by calma.
ron@topaz.rutgers.edu (Ron Natalie) (11/19/87)
Guess again, unary operators are not subject to being applied to assignment operators hence... !=, ~=, -=, &=, *= do not refer to assigning with any of the unary not, complement, negate, address-of, or indirection operation. Some of those (~=) are invalid. != means something completly different. And the rest use their context as a binary operator. -Ron