#81 in -c mode doesn't read previous #includes correctly

[dima]

Suppose you have a source file that contains just the line

#include <stdio.h>

If I build a database and then search for something (without disabling the
cross-reference update with -d) like this

cscope -c -b -i cscope.files -f cscope.out
cscope -c -L4 xxx

I get lots of bogus errors:

Cannot open file

Cannot open file /usr/include/stdio.h

Cannot open file /usr/include/features.h

Cannot open file /usr/include/getopt.h

Cannot open file /usr/include/libio.h

Cannot open file /usr/include/_G_config.h

Cannot open file /usr/include/ctype.h

Cannot open file /usr/include/stdc-predef.h

Cannot open file /usr/include/endian.h

Cannot open file /usr/include/gconv.h

Cannot open file /usr/include/wchar.h

Cannot open file /usr/include/xlocale.h

This happens because the code was reading these files with a trailing newline
and this newline was not being stripped. This patch strips the newline, and the
files can now be read properly.

I'm attaching just the patch since the error is very clearly reproducible (at least here). This patch assumes that newline == '\n'. Is this a valid assumption for cscope even under Windows?

[Hans-Bernhard Broeker]

Hmm... that appears to be a consequence of one of the changes I made a long time ago to address possible buffer overflows (replaced fscanf("%s") by fgets()). And it took only 7 years to find the bug.

Given that, a simpler fix might be to switch this fgets() back to fscanf() (but with a field width this time).

[Hans-Bernhard Broeker]

Decided to go my own way on this.