Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!decwrl!labrea!rutgers!bellcore!texbell!sneaky!gordon
From: gordon@sneaky.TANDY.COM (Gordon Burditt)
Newsgroups: comp.unix.wizards
Subject: Re: Latest indent request
Summary: beware of indenter bugs
Message-ID: <5428@sneaky.TANDY.COM>
Date: 16 Dec 88 08:10:31 GMT
References: <17680@adm.BRL.MIL> <1748@solo3.cs.vu.nl> <366@lclark.UUCP> <1801@solo9.cs.vu.nl>
Reply-To: gordon@sneaky.UUCP (Gordon Burditt)
Organization: Gordon Burditt
Lines: 73

Before anyone gets too enthusiastic about running all code in sight
through indenter/beautifier programs so they conform to THE correct
brace style, be very sure you aren't destroying code in the process.

If you are using a source code control system, and you must run code
through an indenter, it would be an excellent idea to check in all the
code, compile it, save the result, check out the code, beautify it,
compile it, and compare the object files and/or executables.  When you
finally manage to get a match, check in the beautified source (and the
source to the beautifier!) without further changes.  Then check it
out and continue development.  (Some System V compilers put time-stamps or 
other variable information in object headers that won't be the same each 
time you compile.  These differences don't count.)

Beautifiers can destroy code.  I'm not entirely convinced that it is
possible to write a beautifier that properly handles sufficiently
obscure code.   For example:

	char *rcfile = "/usr/foobar/RCFILE; { char *basedir = LIBDIR/rn";

where, unknown to the beautifier, this code is normally compiled with
	cc '-DRCFILE=.foorc"' '-DLIBDIR="/usr/spool/news' ...
so that's TWO declarations, not one, and that brace in the middle
is not inside the string.  Yes, this depends on Reiser CPP operation that
is not standard.  If you want to beautify this code, fix stuff like this
and forget about brace styles.

Few indenters will tolerate code written in this obnoxious outdented style,
especially since it only sees one close brace in the whole program, and
that one is first:
# define END \
	\
	} \
	\


							void doit(foo, bar) {
						if (foo == bar) {
					bark();
					if(2 + 2 != 4) {
				printf("assert error!");
					END

					printf("this code is ugly");
						END
							END
For a less extreme example, how about:
# ifdef BSD
	if (write(socketfd, buffer, length) != length) {
# else
	if (sndmsg(msgid, buffer, length, NO_WAIT) == NULL) {
# endif
		...
	}

I tried using a beautifier called "indent" a few years ago.  This may or
may not have anything to do with any program you know of by the same
name.  It broke things.  The first thing that got mangled was multi-line
# defines, because it didn't know it had to use backslashes on the
continuation lines.  Someone fixed it.  Then it decided to turn
"x= -y;" into "x-=y;" because it thought it was cleaning up old-style
assignment operators.  That took several hours to find.  Someone fixed it.  
Then it decided that *a/*b was the beginning of a comment, and it was free 
to insert line breaks at white space inside that quoted string inside the 
so-called comment.  Someone fixed it.  Then the program acted strange.  
Well, this time it was a bug in the program, but how could I have any 
confidence it wasn't the indenter?  

Now, what does that pre-ANSI indenter do to programs written for your
new ANSI compiler?

				Gordon L. Burditt
				...!texbell!sneaky!gordon