I went to a number of C sessions this SHARE, having acquired a very nice C compiler and debugger for my home computer. I was surprised at the apparent popularity of C within the SHARE community; they are trying to establish a "project" within SHARE that addresses the C language exclusively.

Shawn Elliott is from the IBM Toronto Labs, where C is cared for. He opened his talk by pointing out that "C, like the adz, is neither for fools, nor for small children". C is very powerful, but if you are not awfully careful, you can do some real damage with it. In this way it is like assembly language.

He spent some time talking about the ANSI extensions to C, and the reasons why they are good to use. In particular he likes function prototypes (which were actually invented for use in the C++ language); they allow the C compilers to do some additional checking and parameter conversion when calling subroutines.

He talked about techniques you can use to make your C code portable. One of the problems with C code is that a program will frequently be unable to run on another machine properly, despite the fact that it will compile without errors. This is because C programmers can get into the nuts-and-bolts of the system, and systems are different on that level. As an example, on S/370 and AS/400 machines a character string "ABCD" is stored in order: "A", "B", "C" and "D". On PCs, it is stored in goofy order: "B", "A", "D" and "C". Programmers that depend on the internal representation of character strings get screwed.

Most C implementations allow you to convert a pointer into an integer and vice-versa, so that you can do arithmetic with machine addresses. Such code will rarely work in another system. (On the AS/400, pointers are 48 bits long and so pointer arithmetic is not possible; in fact pointers are security-protected and are invalidated if surreptitiously modified.)

He included general tips for making code more readable and debuggable, and encouraged liberal use of C's macro facility.