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

Standardization to C brought with it a way to annotate variables other than its type: how it is to be accessed. volatile [1] informs the compiler that the value cannot be cached and must always be read from when referenced, because some outside agent (hardware, another process or thread) could have changed the contents since the last read, and const [2], which marks a variable as “read-only,” which means the value can be heavily cached as it won't change what-so-ever.

So today's code is the base version [3] (which is C89 [4]), but with “const correctness.”

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

• 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 */

#include <stdio.h>

#include <ctype.h>

#include <string.h>

#include <stdlib.h>

#define LINESIZE 16

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

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

int main(const int argc,char *const argv[])

{

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];

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);

}

}

}

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

There're no real volatile variables, so there's no use of volatile, but the use of const ensures that I don't change variables inadvertently. One thing to note: The following:

const int *pi;

creates a pointer that can change, which points to memory (interpreted as an integer) that can't change, while:

int *const pi;

creates a pointer that can't change, which points to memory (interpreted as an integer) that can change, while:

const int *const pi;

creates a pointer that can't change, which points to memory (interpreted as an integer) that can't change.

Yes, there are some subtle differences there, and it took me a while to get it down, but you can pin down what can and can't change.

• Part 6: C89, “splint -strict” compliant [5]
• Part 8: C99, const and restrict correctness [6]

=> [1] http://en.wikipedia.org/wiki/Volatile_variable | [2] http://publications.gbdirect.co.uk/c_book/chapter8/const_and_volatile.html | [3] /boston/2012/01/09.1 | [4] http://en.wikipedia.org/wiki/ANSI_C | [5] /boston/2012/01/14.1 | [6] /boston/2012/01/16.1

=> Gemini Mention this post | Contact the author