The compiler finds errors. I do not find any plausible cause. Then I can comment almost all code in, say main, leaving for instance only one instruction. If now the code compiles, I know the fault is within the commented block. I can comment out half the block and find which half is guilty.

Alright. But how do I comment a block that contains /* */ comments? I Pascal there were two kinds of block comments. One was { }, the other I do not remember. Any other way telling the compiler to ignore a block of code?

EDIT:
I search for some #ifdef construct and found (Google) the following much used by developers:

Should be "#if 0", or "#ifdef NOT_DEFINED".

1 members found this post helpful.

Thanks. The compiler objected 'ifdef 0' I had to use some not defined constant as CERO. 'if 0' seems the logical option.

As irritating as this sort of problem may be, it"s usually the cause of a missing closing-quote or something equally stupid. (Just like the one that I purposely put into this response.) It's really hard to spot these things, especially if the program's rambling-on for quite some distance after the actual point where the typo's actually located . . .

C 'lint' packages are sometimes better than actual compilers are, in catching these sorts of problems, basically because they are built to be looking for them.

I generally don't try to use this technique because the odds are too great that omitting some block of code will simply generate other syntax-errors unrelated to the one that I am actually trying to find.

I see but for some reason Pascal had two kinds of comments. When you had a lot of comment blocks of one type, you could always nest them inside a comment block of the other type.

So how did you solve this?

In c++ you can use // at the start of a line to comment it out, not sure if you can use that in c.

Your best bet is to figure out the compiler's errors. Often/Sometimes the error is not on the line that it starts yelling at so that does make it harder.

In my experience it is almost always a stupid quote-mark, and I simply tell the editor to search backwards from the point where the error was detected.

I've also been known to drop syntax-errors into the source at earlier points to see if that syntax-error goes off first.

But in general, with practice you begin to see "where the parser probably fell off the bus." If the grammar used in your compiler is not very thorough, "lint" tools often use much better ones. And they can give better messages, like "Unexpected end-of-file while processing a string literal which began at line 1234, column 5." Wish all compiler-writers thought to do that ...

Some programmer's-editors also support parsing of the source language and can give you feedback cues in real time, e.g. through the use of color or through various lint-like tools that can be run within the editor itself.

1 members found this post helpful.

Well I commented out the whole program first and then I left out of the comment block only the first sentence. Then two sentences and so on until the error appeared. In a few steps the error was put in evidence. I was lucky. It was an unmatched '{' or a ';', I don't remember.

This is why I always use // comments in C (they exist in C as well as in C++). You can nest them into /* comment blocks.