/* 1*/   struct tag {
/* 2*/        int i;
/* 3*/        double d;
/* 4*/   }

/* 6*/   f(struct tag *pst)
/* 7*/   {
/* 8*/      return (pst->i);
/* 9*/   }

line 8 - Expressions are not assignment compatible
line 8 - 'return' : incompatible types

/* 1*/     #include <stdio.h>

/* 3*/     void f()
/* 4*/     {
/* 5*/              int c;

/* 7*/              While ((c = getchar()) != EOF)
/* 8*/                    putchar(c);
/* 9*/     }

line 8 - Syntax error, expected:
        ; <operator> [ ( . -> ,
line 8 - Expecting ; but found fputc

/* 6*/   int f(struct tag *pst)
/* 7*/   {
/* 8*/      return (pst->i);
/* 9*/   }

line 6 - Too many types
        in declaration
line 6 - type following
        struct is illegal

line 8 -   Type mismatch (return)
         (struct = int)

Quite a few years ago, the ability to pass and return structures and unions to/from functions by value was added to the language. Consider the following:

struct tag  {
   int i;
   double d;
};
struct tag f(struct tag *);

struct tag  {
   int i;
   double d;
} f(struct tag *);

As you might expect from this discussion, templates can also be defined within a function's argument list. For example:

void g(struct tag {int i;
      double d;}  *);

2. Well, the first message isn't much help. The second is similar, but refers to fputc instead of putchar. With this compiler, putchar apparently is defined as a function-like macro that expands to a call to fputc. With maximum warning levels activated, the following more useful messages were produced:

line 7 - Warning! No prototype
        found for While
line 7 - Warning: Function While
        not declared

I have seen this problem arise more often with Pascal programmers, who seem to prefer capitalizing leading characters in identifiers. It also happens with If. This is a growing style with X-Windows, MS-Windows and OS/2 programmers.

3. Similar to the previous problem, the compiler objects to the token printf, not because there's something wrong with it specifically, but because such a token cannot be used in this context. The problem is, therefore, "Just what context are we in?"

Perhaps increasing the warning level will help.

line 13 -Warning: Comment within comment
line 13 -Warning! Nested comment found in comment
        started on line 10

/* Disable the following piece
   of code
/* ... */
   printf("Debug data is ..."};
   End disabled section */

So what's all this got to do with our problem? We aren't trying to nest comments! Read the second warning message again carefully. It indicates that a comment was begun on line 10. Do you see it? If not, go into an infinite loop until you do. While the expression i/*pi states exactly what you want, the value of i divided by the value of the int pointed to by pi, what is actually seen is the token i followed by the start of a comment. This comment ends at the next */seen, at the end of line 13. And since another/* is seen along the way, the compiler warns that the start of another comment was seen inside the first comment.

This kind of division expression is not particularly unusual, so how should we write it to get what we really want? Putting white space between the / and * would make it look silly, and some unsuspecting maintenance programmer may well remove it. The best approach is probably to use parentheses as in i/(*p), and to also add a comment to the effect "Don't you even think about removing these seemingly redundant parentheses." (Certainly, indirection has higher precedence than division, so the grouping parentheses are redundant from that perspective.)

Regarding the nested comment issue, "If I really want to disable code containing comments, how do I do it?" The solution has always been to use the preprocessor in a non-intuitive manner. That is, to conditionally compile code such that it is never accepted. For example:

#if 0 /* Disable the following piece of code */
printf("Debug data is ..."); /* ... */
#endif/* End disabled section */

4. I admit this is a contrived puzzle — I have never actually seen anyone accidentally trip over it. However, it's still interesting. Since the switch controlling expression matches neither of the cases, you would expect control to pass to the default label. Clearly this did not happen since no output resulted.

According to PC-Lint though, there is something suspicious.

line 13 -  switch statement has no default
line 14 -  default (line 11) not referenced