If you are doing this because "you don't have to worry about being that portable" or "it works on my PC," then I suggest changing the name of the magazine to The MS-DOS C User's (who also don't care about porting or standards) Journal. What is so terrible about the following?

...
int int_compare(const void * p1, const void * p2)
   {
   int i1 = * (const int *) p1,
     i2 = * (const int *) p2;
   }
...
qsort (int_array, num_elements, sizeof(int), int_compare);

After rereading this letter, I feel I should make it clear that I am not as mad or disgusted as it may seem. I enjoy reading your magazine every month (the University library subscribes), although I wish you would adhere more to the ANSI standard when answering questions

Jamshid Afshar
Austin, TX 78751

A

You are right that void * pointers may not have the same size as int * pointers. (If you know of a system where these pointers don't have the same size, I would like to hear about it.) On many systems, including the IBM-PC, int * () (function pointers) may not be the same size as int * or void *.

I can easily defend my usage for just the reason you mention: "There are too many ... buggy C programs." With your approach, it would be easy to use the comparison function inappropriately outside of the context of the qsort. For example:

int int_compare(const void * p1, const void * p2);
double d;
char c;
if (int_compare(&d, &c))
   ...

int int_compare(const int *, const int *);
double d;
char c;
if (int_compare(&d, &c))

int silly_int_compare(double *);
qsort (buffer, number, size, (fcmp_t) silly_int_compare);

Q

Using curses, I coded something like the following:

while (!done)
{
move (10,10);
printw("Default value");
move (10,10);
refresh ();
gets (char_array);
/* More code */
}

Larry Meyer
Bahama, NC

A

Originally, the curses library was intended to provide terminal-independent screen positioning routines for use over low-speed lines.

The package keeps an internal representation of how it thinks the terminal screen appears, as well as a representation of the modifications you want to make. When you make curses calls, such as printw, this internal representation is updated. No characters are sent to the terminal screen until you call refresh.

When you call refresh, curses determines the minimum number of characters to send to update the real terminal screen so that it agrees with the representation of the modified screen. This so-called cursor optimization gives rise to the name curses.

For example, if you write

move (10,10);
printw("Default value");
move(10,24);
printw("Another value");
refresh ();

CURSOR TO 10, 10
Default value Another value

When you called refresh the second time, the internal representation had not been modified, since you used the standard I/O function gets (). You must use the curses function getstr(char_array) to update the internal representation.

Note that running under most MS-DOS-based packages, cursoring or writing strings updates the real screen directly. There is no refresh () function.(KP)

Q

As I understood, one of the great advantages of Object Orientation as the ability to encapsulate and hide implementation. I have now struck this problem.

For example, a common C idiom is:

while ( (c = getchar()) != EOF)
   {
   /* Do something */
   }

for(;;)
   {
   c = getchar();
   if (c == EOF)
        break;
   else
        /* Do something */
   }

eof = FALSE;
while (!eof)
   {
   c = getchar();
   if (c == EOF)
        eof = TRUE;
   else
        /* Do something */
   }

while ((c = getchar()) && c !=
   EOF && c != '\032' && c !=
   '\177' )
   {
   if (c == 'A' || == 'B'
       || c == 'D')
         /* Do something */
   else if (c == 'D' || c == 'E')
        /* Do something else */

   }

done = FALSE;
while (!done)
   {
   c = getchar();
   switch(c)
        {
   case EOF:
   case '\032':
   case '\177':
        done = TRUE;
        break;
   case 'A':
   case 'B':
   case 'C':
        /* Do something */
        break;
   case 'D':
   case 'E':
        /* Do something else */
        break;
   }
   }

Of course, if you are after maximum speed, then the test expression with the embedded assignment statement may compile to faster code. However, if you used the first form as this:

for(;;)
   {
   c = getchar();
   switch(c)
     {
     case EOF:
     case '\032':
     case '\177':
         goto end;
         break;
     case 'A':
     case 'B':
     case 'C':
         /* Do something */
         break;
     case 'D':
     case 'E':
         /* Do something else
*/
         break;
     }
   }
end:

You may notice that there is an unreachable statement in this code. The break following the goto is not needed. I have a tendency to leave it in for consistency's sake. It makes that set of statements for the case appear like all other sets. Likewise it is needed in the form with the done flag.

Which approach is best? Whichever one works for you consistently.

Names are another area of readability that I have harped on in the past. I have just started teaching OSF UNIX internals, since it is now becoming available. Much of the kernel has been adopted from BSD. It is quite clear from the code which parts have been added. The BSD code (which was written with an eight character name limit) and the OSF code (with a 32 character limit) stand distinctly apart.

New OSF system calls include task_set_special_port() and thread_suspend(). Members of the kernel structure vm_object (a virtual memory object) include paging_in_progress, resident_page_count, and con_persist. Code can be read without resorting to an internal associative table in your mind.

As far as whether the Hungarian style (aVeryLongName) or the underscore style (a_very_long_name) is better, I offer the following advice.

Use whichever one you (and your colleagues) agree on. You may note my preference from the examples I use in this column. Schoolday admonitions about following capitalization rules may have something to do with this approach.

Another important use of this was writing firmware in parallel C for transputers. Using 3L's parallel C and positioning time critical functions first, they are placed in the transputers local memory, which has a much faster access time than the external memory. Note the configuration file must also reflect that the code should be placed in the local memory and not data.

Adrian Kemp
Bucks, England

You have some good points. If I need to know the length of a function, I usually put some sort of dummy function after it.

In addition to the hardware you mentioned, placement of functions may affect execution time in paged machines. If functions that constantly call each other are spread over a large address space, the number of pages required for efficient program execution (called the "working set") might be significant. On a single-task system, placement has no effect unless the real memory was significantly limited.

On a multi-tasking system, however, a memory hogging program can affect its own execution, either by being swapped out or by requiring other programs to be swapped out. If time and/or space is critical in your program, you should worry about function order. (KP)