Starting with Hello World

By Bob Gordon, Apropos Publications, Minneapolis, MN

Welcome to How to C. This series will explore use of the C language on the Macintosh for those who don't know C and may have fairly limited experience programming the Mac. Put another way, if you often have the feeling that you don't know what's going on, this is a place to get your bearings.

You'll find the following items useful to have around if you want to do more than program vicariously:

• Using the Macintosh Toolbox with C by Takatsuka, Huxham, and Burnard (Sybex, 1986). This will serve as our 'text.' It is currently the best available book on C on the Mac. We will generally follow their order of topics.

• The C Programming Language by Kernighan and Ritchie (Prentice-Hall, 1978). If you are going to use C, you need this book. It is an amazingly clear and concise discussion of the language.

• Inside Macintosh. Mainly because the first book does not cover everything.

• A C development system. A number of compilers are available. We'll focus on Consulair's Mac C because the Using the Macintosh Toolbox book uses it, and because it uses MDS. If you're using a different compiler, don't worry. C is one of the more portable languages (between compilers and machines), and I'll try to point out differences when they appear.

I'll also mention other useful sources of which I am aware. If you have any favorite books or articles, send me a note so we can share the information.

Why Use C / Why Not Use C

C was designed to be suitable for systems programming. As such, it is very flexible and allows programmers to do pretty much as they please. C is often characterized as a 'medium level' language. It offers the control mechanisms and data structures of a higher level language but at the same time allows access to the hardware and the ability to handle data in any way that seems suitable at the time. The compilers typically generate fairly fast, compact code.

This flexibility is not without its costs, however. It is very easy to make a real mess of things (and generate incendiary devices on the Macintosh) by not getting the types of parameters correct. And some C notation can be downright cryptic. It is easy to make C code unreadable.

In spite of the problems, I prefer C to Pascal. I could usually do what I wanted with Pascal (depending on the compiler), but I knew I was cheating. And I could never be sure the technique would work the same way with a different compiler.

Problems Using C on the Macintosh

One problem with C vis-à-vis the Macintosh is that much of the C literature and many of the standard library functions assume you are using Unix or a Unix-like operating system. As you may have noticed, the Macintosh does not. This poses an additional set of problems for learning C on the Mac. The compiler makers follow two approaches. Some ignore Unix; others make the Mac look like it's running Unix.

A second problem is that the Macintosh operating system assumes applications will be written in Pascal. This presents problems in at least two areas: strings and parameter passing.

A C string is an array of bytes with a terminating zero (a byte of all zero bits, a binary zero, the null character, represented in C by \0). A Pascal string, as far as the Macintosh is concerned, is an array of bytes consisting of a leading byte containing the number of bytes in the string followed by the bytes of the string. Obviously sending a C string to a Toolbox function is not going to yield any sort of desired result. The compiler makers have solved this problem in two ways. Some compilers automatically convert the string when its passed; others provide a C function to do the conversion that you call before calling the Toolbox function (and another function to reconvert the string). Check your compiler's documentation to see what it does.

The parameter passing problem involves a number of issues: where parameters are passed (stack or registers), the order in which they are passed, and how complex data types are passed. Most of the time you need not to be concerned with this at all; your compiler will do the necessary translations. In some cases (with some compilers) you must be aware of the difference.

Getting Started

The first program we'll do is the first program in Kernighan and Ritchie. This will force us to figure out how to set up our compiler, and use the editor, compiler, and linker. Now, at this point I should simply recount my experiences in getting "hello, world" to appear on my screen. Unhappily, I only recently received the compiler so I haven't done it yet. I also do not have two Macs so excuse me while I figure this out.

This month I've got Mac C™ from Consulair. It comes with three booklets of documentation, a letter from the author Bill Duvall, and some information sheets. One sheet describes the contents of the four disks. They include a public domain ram disk program written in Mac C called RamStart, so the first thing I did was to set up a ram disk.

Using RamStart is a bit exciting. A help button is available, but if you don't click it fast enough, RamStart goes ahead and makes the ram disk. I don't remember exactly how I found that out: it is, of course, in the instructions, but you can't read the instructions unless you click help. Catch 22. Actually, the program is quite easy to use. Simply put what you want in the ram disk in the same folder with RamStart, and it creates the disk with those files in it. With Mac C, you may not have a ram disk larger than 280 K bytes (on a 512 K machine) or the compiler will run out of room.

The Mac C package includes Edit, the four window mouse-driven program editor. Edit allows transferring directly to the compiler so you can invoke the compiler directly from Edit.

hello, world

Using Edit, I typed in the first program most people learning C try, a program to print "hello, world" on the screen.

#include  "stdio.h"

/* traditional first C program */
main()  
{
  printf("hello, world"); 
}

That's the program. If you have never seen a C program before, there is a lot to examine even in this.

The first line specifies an include file. This is a separate file that you wish to include as part of the compilation. These files typically contain constants, references to external functions, new symbols, and macros, but they can contain any code you wish to include.

Here are some parts of the stdio.h that comes with Mac C:

// stdio.h  

The double slash means comment to the end of the line. This is not standard.

// Copyright 1984 Consulair Corporation.
// All rights reserved

// Aug 30, 1984 2:43 PM: New File
// Standard UNIX IO library defs for MacC

    #define ERROR -1
    #define EOF -1
    #define NULL 0
    #define MAXLINE 255
    #define FILE int

The defines are instructions to the C preprocessor. These supply names to some oft-used values. In a program, you can use the name and the preprocessor will replace it with the value. By the way, standard C practice requires the "#" be in the first column. Mac C allows it anywhere on the line as long at is is preceded only by white space.

// Standard Routines

  extern char putchar();
  extern char fputc();
  extern long putl();
  
  extern int printf(...);

There are references to external functions. External functions are functions defined in another file. For the compiler to work correctly, it needs to know the type of object returned, if any. Here we see that putchar returns a type char, putl returns a long, and printf returns an int. Most C compilers have a separate include file for each chapter in Inside Macintosh to provide the necessary definitions.

To return to our program, the next line is:

/* traditional first C program */

This is a comment. The "/* */" bracket comments.

main()

Every C program must have one and only one main function. It is where execution starts. Function names always have parentheses after them even if they have no parameters.

{
  printf("hello,world");
}

The braces define a block of code that is handled as one line for program control purposes. They are similar to Pascal's begin-end.

The only piece of code that does anything here is printf. It is used to write strings on the screen (the standard output device). It is not actually part of the language but is part of the standard library. The semicolon is a line terminator.

A few comments are in order concerning other compilers. Mac C creates a TTY window for the standard C I/O functions. Other compilers may write directly to the desk top or require that you create a window for them. You will have to check the documentation.

Next month we'll look at some more basic C concepts and start dealing with using C in the Macintosh environment.