Path: utzoo!utgpu!attcan!uunet!lll-winken!ames!vsi1!daver!lynx!m5
From: m5@lynx.uucp (Mike McNally)
Newsgroups: comp.unix.wizards
Subject: diff
Summary: diff -D output not necessarily useful
Message-ID: <5174@lynx.UUCP>
Date: 7 Jan 89 01:21:12 GMT
Reply-To: m5@lynx.UUCP (Mike McNally)
Distribution: na
Organization: Lynx Real-Time Systems Inc, Campbell CA
Lines: 33

While hacking on GNU diff to add the -D option, I noticed a seemingly
unavoidable problem with the whole concept.  The -D option generates
from two input files a single file containing all common lines from the
files, along with differences cleverly surrounded by cpp-style #ifdef's
(actually #ifndef's).  The idea is to produce a single source file from
two C modules (I guess it could be anything that normally gets cranked
through cpp on its way to fulfillment) and then get either version by
appropriate compilation switches.

The problem does not really lie with diff.  Rather, it appears because
cpp eats comments, and thus confuses itself.  Consider this possible
output from diff -DBALLOON version1.c version2.c:

/* This is the beginning of a multi-line comment.  It describes a certain
#ifndef BALLOON
   C function, which might be used to open text files.  The comment ends
#else BALLOON
   C function, which might be used to close text files.  The comment ends
#endif BALLOON
   with a single uninteresting line. */

The preprocessor can't deal with this setup; the interaction of #things and
comments causes lots of problems.

Is my cpp screwed up (Greenhills)?  Should I worry about this?  Are there
ways known to smart people to avoid these problems?  Is the -D option
ever used anyway?  Did I waste my time kludging it into GNU diff?

-- 
Mike McNally                                    Lynx Real-Time Systems
uucp: {voder,athsys}!lynx!m5                    phone: 408 370 2233

            Where equal mind and contest equal, go.