Of course, the compiler sees the filename as a tab character followed by est.dat. Why didn't the tab get displayed in the output? It did, but the tab stops of the terminal were set such that the tab was not obvious.

The solution? Use \test.dat instead. Now the compiler sees no escape sequence.

Note that according to ANSI C, a different rule is applied with the #include preprocessor directive. For example,

#include "\test.h"

2. It is not unreasonable to expect the following output:

??(Error: message)

[Error: message)

line 5 - Trigraph Sequence '??(' in literal (Quiet Change)

3. Yes. Before a function can be called, each of its arguments must be evaluated. Then their values are put into the function's call frame. A compiler is not required to know anything about any of the standard library functions (although it is permitted to), so provided the actual argument list is compatible with the function's prototype, the call is OK. In this case, the ellipsis notation is used in the printf prototype so there's no conflict.

Interestingly, PC-Lint had the following to say:

line 7 - number of arguments inconsistent 'with format

4. On the 16-bit compilers I tested, by far the most common output was

i = -32768

i = -1

One compiler gave the following hints as to why:

line 7 - Function f has no prototype
line 7 - Constant has long type 
line 10 - Parameter list for f is inconsistent with previous call

By adding a prototype in main for f, of the form

/* 5*/ void f(int);

Now, back to the type of -32768. In the April 1990 issue of CUJ (Volume 8, Number 8), I made the following statement: "An expression such as -32768 consists of two source tokens; the unary minus operator and the integer constant 32768. Note there is no such thing as a negative constant in C. The constant is non-negative and it is preceded by a unary minus operator. An interesting situation exists on 16-bit twos-complement machines where -32768 is the smallest value that can be stored in an int. It so happens that the type of -32768 when written in this form is not int; it's long int, but that's another story."

This resulted in reader mail (and subsequent reply), but here is the explanation.

According to the ANSI Standard, (page 28, lines 37-41), "The type of an integer constant is the first of the corresponding list in which its value can be represented. Unsuffixed decimal: int, long int, unsigned long int; unsuffixed octal or hexadecimal: int, unsigned int, long int, unsigned long int; suffixed by the letter u or U: unsigned int, unsigned long int; suffixed by the letter 1 or L: long int, unsigned long int; suffixed by both the letters u or U and 1 or L: unsigned long int."

32768 is an unsuffixed decimal, and it won't fit into an int. The compiler tries long and it works, so long is its type. The compiler then applies negation to the result of that long int. If you look carefully, you will see that the rules are different for decimal and octal/hex. The following program demonstrates this:

#include <stdio.h>
main() {
printf("sizeof(-32768) = %lu\n",
   (unsigned long)sizeof(-32768));
printf("sizeof(0x8000) = %lu\n",
   (unsigned long) sizeof(0x8000));
printf("sizeof(0100000) = %lu\n",
   (unsigned long)sizeof(0100000));

sizeof(-32768) = 4
sizeof(0x8000) = 2
sizeof(0100000) = 2

The problem is that the language supports a null statement represented simply by a semicolon. As a result, spurious semicolons may be hazardous to your program, as in the previous example. The trailing semicolon on line 7 represents a null statement that is subsequently taken as the body of the loop. The call to printf, therefore, occurs once, after the loop terminates. In this case, the output indicates the problem, but in cases where the actual loop body produces no visibly strange behavior, the problem can be difficult to find.

PC-Lint did issue the following, very useful message:

line 7 - Suspicious use of ;

6. We all know that you must explicitly declare an identifier before using it. Of course, many rules have exeptions, and the obvious one here is for functions. If the compiler comes across a call to an unknown function, it presumes that function returns an int. It is not able to check the argument list because no prototype is available.

There is one other, very obscure exception. If you omit the type from any formal arguments in a function definition, the compiler assumes that the argument has type int. The following old-style definitions are equivalent:

double f(i, j)
   int i, j;
   {}
double f(i, j)
   int i;
   int j;
   {}
double f(i, j)
   int i;
   {}
double f(i, j)
   int j;
   {}
double f(i, j)
   {}

double f(int i, int j)
   {}

double f(i, int j)
   {}
double f(int i, j)
   {}