The Boston Diaries

The ongoing saga of a programmer who doesn't live in Boston, nor does he even like Boston, but yet named his weblog/journal “The Boston Diaries.”

Go figure.

Tuesday, January 17, 2012

99 ways to program a hex, Part 9: C89, const correctness, assertive

This is a minor variation on part 7—the use of assert():

/*************************************************************************
*
* Copyright 2012 by Sean Conner.  All Rights Reserved.
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version 2
* of the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.
*
* Comments, questions and criticisms can be sent to: sean@conman.org
*
*************************************************************************/

/* Style: C89, const correctness, assertive */

#include <stdio.h>
#include <ctype.h>
#include <string.h>
#include <stdlib.h>
#include <assert.h>

#define LINESIZE	  16

static void 	do_dump		(FILE *const,FILE *const);

/****************************************************************/

int main(const int argc,char *const argv[])
{
  assert(argc    >= 1);
  assert(argv    != NULL);
  assert(argv[0] != NULL);
  
  if (argc == 1)
    do_dump(stdin,stdout);
  else
  {
    int i;
    
    for (i = 1 ; i < argc ; i++)
    {
      FILE *fp;
      
      fp = fopen(argv[i],"rb");
      if (fp == NULL)
      {
        perror(argv[i]);
        continue;
      }

      printf("-----%s-----\n",argv[i]);
      do_dump(fp,stdout);
      fclose(fp);
    }
  }

  return EXIT_SUCCESS;
}

/******************************************************************/

static void do_dump(FILE *const fpin,FILE *const fpout)
{
  unsigned char  buffer[BUFSIZ];
  unsigned char *pbyte;
  size_t         offset;
  size_t         bread;
  size_t         j;
  char           ascii[LINESIZE + 1];
  
  assert(fpin  != NULL);
  assert(fpout != NULL);
  
  offset = 0;

  while((bread = fread(buffer,1,BUFSIZ,fpin)) > 0)
  {
    pbyte = buffer;
    while (bread > 0)
    {
      fprintf(fpout,"%08lX: ",(unsigned long)offset);
      j = 0;
      do
      {
        fprintf(fpout,"%02X ",*pbyte);
        if (isprint(*pbyte))
          ascii [j] = *pbyte;
        else
          ascii [j] = '.';
        pbyte  ++;
        offset ++;
        j      ++;
        bread  --;
      } while ((j < LINESIZE) && (bread > 0));
      ascii [j] = '\0';
      if (j < LINESIZE)
      {
	size_t i;

	for (i = j ; i < LINESIZE ; i++) fprintf(fpout,"   ");
      }
      fprintf(fpout,"%s\n",ascii);      
    }
    
    if (fflush(fpout) == EOF)
    {
      perror("output");
      exit(EXIT_FAILURE);
    }
  }
}

/***************************************************************/

Writing Solid Code is one of only two programming books that really change how I write code (the other being Thinking Forth but that's for another episode post), begining with the liberal use of assert() to, well, not validate input parameters, but to enforce that they're valid.

Prior to this book, I wrote defensive code, so prior to reading the book, I would have coded do_dump() as:

static void do_dump(FILE *const fpin,FILE *const fpout)
{
  /* vars vars vars */

  if ((fpin == NULL) || (fpout == NULL))
    return;

  /* rest of code */
}

Not very much code (and in this code, useless as well), but in a larger codebase, it does add up. And it hides problems with the code. The first project I liberally used assert() I really went crazy with it. The codebase implemented “window regions” on a text screen, and every routine used assert() to not only check that I didn't slip in a NULL pointer, but that every field of all the structures I defined had reasonable values.

And doing so saved me a lot of debugging time in the corner cases, like, what exactly does it mean to have a “window” that's only one character wide? Or even a window that's one character wide by one line high? The assert()s would trip up on all sorts of corner cases like this, and given that I was programming the code under MS-DOS, an errant pointer could not only crash the program, but the entire machine (at best—at worst, it could corrupt memory that wouldn't be detected until some other program ran).

I still use assert()s to this day.

Now, I'll grant you the following bit of code:

int main(const int argc,char *const argv[])
{
  assert(argc    >= 1);
  assert(argv    != NULL);
  assert(argv[0] != NULL);

is going a bit too far, only because this is guaranteed to be true by the C standard, and if it's not, I have more pressing issues to worry about.

The network? A firewall? A bug? A misconfiguration? Gremlins? Who knows?

“In a system of a million parts, if each part malfunctions only one time out of a million, a breakdown is certain.”

—Stanislaw Lem

So it's Regression Test Time™ again (for “Project: Wolowizard”) at The Ft. Lauderdale Office of the Corporation, only this time, with new, addtional regression tests!

Joy.

Okay, it's not too bad. It's a rather simple matter to add the cases to a master list of test cases and expand the program that uses this list to generate the data used for the regression test. That was probably about an hour or so of work. Then a minor change to the actual test program to make sure it fires off the messages under the right conditions (two different messages, ten cases, a 100×100 matrix, but easy enough to code).

Then, generate all the data, copy it all out to the four servers required to run the test, get the latest build of all the programs, move them out to the test servers, make sure the configuration files are up to date on all the servers, make sure The Protocol Stack From Hell™ won't puke, and fire up the regression test.

Only to have one component fail each test because it can't communicate with another component.

Aaaaaarg!

SM and I spent the next few hours troubleshooting the issue. The two components are on different servers, but they can see each other. Doing a manual query at the command line shows the query going through. But something deep within the bowels (maybe below the cockles, maybe in the sub-cockle area, maybe in the liver, maybe in the kidneys, maybe even in the colon. We don't know …) of “Project: Wolowizard” is munged.

Sigh.

Obligatory Picture

[The future's so bright, I gotta wear shades]

Obligatory Contact Info

Obligatory Feeds

Obligatory Links

Obligatory Miscellaneous

You have my permission to link freely to any entry here. Go ahead, I won't bite. I promise.

The dates are the permanent links to that day's entries (or entry, if there is only one entry). The titles are the permanent links to that entry only. The format for the links are simple: Start with the base link for this site: https://boston.conman.org/, then add the date you are interested in, say 2000/08/01, so that would make the final URL:

https://boston.conman.org/2000/08/01

You can also specify the entire month by leaving off the day portion. You can even select an arbitrary portion of time.

You may also note subtle shading of the links and that's intentional: the “closer” the link is (relative to the page) the “brighter” it appears. It's an experiment in using color shading to denote the distance a link is from here. If you don't notice it, don't worry; it's not all that important.

It is assumed that every brand name, slogan, corporate name, symbol, design element, et cetera mentioned in these pages is a protected and/or trademarked entity, the sole property of its owner(s), and acknowledgement of this status is implied.

Copyright © 1999-2024 by Sean Conner. All Rights Reserved.