This one bit me today
Richard O'Keefe
ok at cs.mu.oz.au
Mon Oct 9 16:58:42 AEST 1989
In article <2063 at frog.UUCP>, john at frog.UUCP (John Woods) writes:
: In article <2432 at hub.UUCP>, dougp at voodoo.ucsb.edu writes:
: > -Message-Text-Follows-
: < main()
: > {
: < int a=1,b=2,*p=&a,c;
: > c=b/*p;
: < }
: > First real flaw in the C grammer I have found.
:
: usespacestheymakeyourcodemuchmorereadableandhappentoavoidthisproblemasa
: pleasantsideeffectparentheseswouldalsobehandysincepunctuationcanbeyourfriend
I am getting just a little bit sick of these "blame the victim" responses.
BCPL did not have this problem, because BCPL used //... end of line comments.
PL/I did not have this problem, because although it had /*...*/ comments,
the character sequence / * had no other possible significance (although when
feeding PL/I card decks to DOS/360 you had to be careful not to start a
comment in column 1, but that's another story). The problem _is_ due to
the fact that /* is potentially significant in C.
We had a similar discussion last year (or was it the year before), and
a couple of people posted programs that would help you find this mistake.
One scheme that works rather nicely is to write a Lex script that copies
characters from stdin to stdout, inserting a <begin-bold> sequence just
before /* and an <end-bold> sequence just after */, where these sequences
depend on your terminal (if you have the 'more' program, another idea would
be to echo each character c between and included /* and */ as _^Hc; more
will then try to get underlining or some other highlighting scheme on your
screen). What you then do is feed your program through this filter, and it
is glaringly obvious where the comments begin and end.
I have written such a program to cover a variety of languages (Lisp, Pascal,
C, shell scripts, &c) and it's really handy because it often pays to skim
through a program just looking at the comments anyway.
Here is a totally simple-minded version of the program. It doesn't
understand strings or quoted characters; that isn't hard to handle.
It can't prevent /* errors, but it will help you locate them.
/* seecom.c -- highlight comments in C programs
Usage: seecom <foobaz.c | more
(relies on more(1) to handle underlining)
*/
#include <stdio.h>
main()
{
int state = 0;
int c;
while (c = getchar(), c != EOF) {
if ((unsigned)(c-1) < ' ') {
/* don't underline or highlight layout characters */
putchar(c);
} else
if (state) {
/* we are inside a comment */
/* echo _^Hc and check for '*' '/' */
putchar('_');
putchar('\010');
putchar(c);
if (c == '*') {
c = getchar();
if (c == '/') {
putchar('_');
putchar('\010');
putchar(c);
state = 0;
} else {
ungetc(c, stdin);
}
}
} else {
/* we are not inside a comment */
/* check for '/' '*' */
if (c == '/') {
c = getchar();
if (c == '*') {
printf("_\010/_\010*");
state = 1;
} else {
ungetc(c, stdin);
putchar('/');
}
} else {
putchar(c);
}
}
}
if (state) {
fprintf(stderr, "Unterminated comment\n");
exit(1);
}
exit(0);
}
More information about the Comp.lang.c
mailing list