Re: Mini-patch for cccp.c

[Thomas Koenig <ig25 at mvmap66 dot ciw dot uni-karlsruhe dot de>]

Paul Koning wrote:

>Since lots of structs have padding all over the place, what you
>describe is clearly a Checker bug.  It doesn't make sense to me to
>change one of the many structs in one of the many programs to work
>around this bug.

That's not the only reason for this change, although this prompted it.

If you look at finclude() in cccp.c, you'll find this code:

static void
finclude (f, inc, op, system_header_p, dirptr)
     int f;
     struct include_file *inc;
     FILE_BUF *op;
     int system_header_p;

[...]

  FILE_BUF *fp;

  fp->system_header_p = system_header_p;

Now, system_header_p has to be an int beause there might be a K&R
compiler which, without prototypes, promotes a char to an int.  OTOH,
fp->system_header_p is a char.  Does this add to the clarity of the
code?

In another place, system_header_p is used not as a boolean, but as a
small int, i.e. in do_line():

static int
do_line (buf, limit, op, keyword)
     U_CHAR *buf, *limit;
     FILE_BUF *op;

[...]

      if (*bp == '1')
        file_change = enter_file;
      else if (*bp == '2')
        file_change = leave_file;
      else if (*bp == '3')
        ip->system_header_p = 1;
      else if (*bp == '4')
        ip->system_header_p = 2;

To use a char in such circumstances appears to me very, very unclean.
-- 
Thomas Koenig, Thomas.Koenig@ciw.uni-karlsruhe.de, ig25@dkauni2.bitnet.
The joy of engineering is to find a straight line on a double
logarithmic diagram.