int const i = 5;

const int i : 5;

Although you probably would not use this for a single integer in place of a #define, you might use this for an array or structure that was initialized and never altered.

The keyword static is used for local variables whose memory is allocated at load time. You can initialize static variables and not change them. However the compiler does not prevent you from accidentally writing over their initial contents. The const variable is designed to protect against that occurrence. Its protection is compiler dependent, not absolute. A particular compiler/processor pair may not support read-only memory.

The possibilities with static and const are:

static int i = 5;            /*  Static variable whose contents may change */
static int const i = 5;      /*  Static variable whose contents will not be changed */
int const i : 5;             /*  Variable whose contents will not be changed */

char const *pc1;  /*  const char *pc1; */
char * const pc2;

char const c_const;
char const another_c_const;
char const *pc1;
pc1 = &c_const;

*pc1 = 'A';

pc1 : &another_c_const;

On the other hand, pc2 is a constant pointer to characters that can change. For example, with:

char variable_c;
char another_variable_c;
char * const pc2 = &variable_c;

*pc2 = 'A';

pc2 = &another_variable_c;

Because of pointers, I prefer placing the const after the type. If you declare:

const char *pc1;

char * const pc1;

Note that you can assign a less constant type to a more constant type. For example, the following is valid:

char *pc3;
char const *pc1;
pc1 = pc3;

*pc3 = 'a';  /*  Valid */
*pc1 : 'a';   /*  Invalid */

char const * const pc3 = c_const;

*pc3 : 'A';
pc3 : &another_const;

char const char_const;
char variable_char;
char * ptr;
char const * ptr_to_char_const;
char * const ptr_const_to_char = &variable_char;
char const * const ptr_const_char_const;

char ** ptr_to_ptr_to_char;
char const ** ptr_to_ptr_to_char_const;
char * const * ptr_to_ptr_const_to_char;
char ** const ptr_const_to_ptr_to_char = &ptr;

ptr_to_ptr_to_char = &ptr;
ptr_to_ptr_to_char_const = &ptr_to_char_const;
ptr_to_ptr_const_to_char = &ptr_const_to_char;

char const * const * ptr_to_ptr_const_to_char_const;

This is not needed for the parameters themselves, as a copy is always passed to the function. With ints, for example, it is redundant to state in a prototype:

int integer_compare_function ( int const integer1,
   int const integer2);

int change_strings(char * const string);

If the actual strings are not going to be changed, then you would code the prototype as:

int string_compare_function(char const *string1,
   char const *string2);

*string1 = 'a';

string1 = string2;

int string_handle_compare_function(char const * const
   * string1, char const * const * string2);

* string1 = *string2;
**string1 = 'a';

You said, "Your style has a lot going for it." While there is nothing particularly bad about his style of indentation, it seems to me to be a classic case of a solution to a non-problem for two reasons:

1) Even given his program as it stood, he could just have drawn a line to the left of the braces which would not then have run through the first character of the code. Ensuring that all the code was legible would seem to be a basic precaution taken before debugging.

2) What are aflag and eflag doing in a serious program? Variables should have meaningful names with a minimum Hamming distance between them, i.e., they should differ in a number of positions.

Donal Lyons
Dublin, Ireland

The style to which you refer in #1 looked like:

for (...)
   {
   /* Internals indented one space to right of brace */
   }

Janet Price
Kalamazoo, MI

You are correct. The printf buffer is usually not dumped to the screen until a \n appears. Without the code though, it is difficult to state precisely what went on. (KP)

The reason this data may be so used has to do with stack usage. Each time the function repeat_format is called, space is reserved on the stack for local data. My compiler (Turbo C 1.5), and perhaps his (he used QuickC), places the string space for newfmt[] farthest away in the stack area from BP (the processor register relative to whose value local variables and parameters are referenced in the compiled functions' code). Also, the 256 bytes reserved for newfmt[] in repeat_format is nearly 100 bytes longer than any of the format strings generated by the sample driver.

In the sample driver and in the recursive calls within repeat_format, it is used as the source parameter to strcpy, e.g. strcpy(newstr, repeat_format(fmtstr[i])), whose stack uses a portion of repeat_format's now-invalid data area. Fortunately, in this case other local variables, which are not used for anything after the function returns, are the victims.

To verify this, I changed a copy of the C source so that newstr[152] was used as the last local data item declared in repeat_format. (152 is only slightly longer than the minimum string length necessary to hold the longest format string returned to the sample program.) The result was that, when run, garbage was displayed at the end of the longest format string. As long as repeat_format is left in its original form, and used as a source parameter for strcpy, it should be safe-tempstr[]. The other local variables provide more than enough room for strcpy to execute safely.

It should be noted, though, that the function is somewhat stack-hungry, requiring approximately 350 bytes minimum per call, and could run into trouble in some memory models if deeply-nested format strings were expanded in a data-intensive application.

I also found it interesting to use this function with dprintf, which also appeared in The C Users Journal (September 1990). By modifying dprintf so that it uses repeat-format to expand the format string passed to it, and passing this result to vdprintf, format strings with repeat format specifiers may be treated as ordinary format specifiers in calls to dprintf.

While testing these functions, I decided to check them for Microsoft compatibility with Learn C, a subset of QuickC developed by Microsoft and marketed by Microsoft Press. Unfortunately, dprintf would not run under Learn C, but, instead, generated the message unresolved external: ftol. I subsequently found out that it would not convert from float to int. I am still waiting to hear from Microsoft about the problem as of this writing.

Thank you. I enjoy your column and The C Users Journal.

John W. Bandy
Armuchee, GA

Thank you for your analysis of the code. Using the address of an automatic variable, when that variable is no longer allocated, is a cause for indeterminate code. The algorithm here will work as long as the processor/compiler does not make the previously allocated storage unavailable (i.e., to cause an addressing exception to occur).

One could allocate a large static buffer to fill up with the generated string and return the address of that buffer. This is the way that some standard library routines work. Whether statics or automatics are used, the routine should check to see it does not exceed the length of the array. Some compilers allocate automatic variables on the same stack used for return addresses. Exceeding array limits causes interesting debugging problems on those machines. (KP)