头文件中的代码似乎会导致编译错误

Question

I have a CLI program consisting of a single vt.c file that compiles and runs under Windows (cmd.exe) using Open Watcom. I can also compile it for Linux while running Open Watcom on Windows (and the resulting build runs under linux).

When I try to compile it under linux however (using make, which calls cc), I get 375 lines of error messages. Here are some of them, where many subsequent errors were similar, I have only pasted the first few:

In file included from vt.c:4:0:
process.h: In function ‘__declspec’:
process.h:45:22: error: storage class specified for parameter ‘execl’
process.h:46:1: error: expected declaration specifiers before ‘__declspec’
process.h:47:1: error: expected declaration specifiers before ‘__declspec’
...
In file included from vt.c:5:0:
ctype.h:48:1: warning: empty declaration
ctype.h:81:37: error: storage class specified for parameter ‘__ctype_b_loc’
ctype.h:82:6: warning: ‘__nothrow__’ attribute ignored
ctype.h:83:28: error: storage class specified for parameter ‘__ctype_tolower_loc’
ctype.h:84:6: warning: ‘__nothrow__’ attribute ignored
ctype.h:85:28: error: storage class specified for parameter ‘__ctype_toupper_loc’
ctype.h:86:6: warning: ‘__nothrow__’ attribute ignored
...
In file included from vt.c:6:0:
string.h:44:14: error: storage class specified for parameter ‘memcpy’
string.h:46:6: warning: ‘__nothrow__’ attribute ignored
string.h:49:14: error: storage class specified for parameter ‘memmove’
string.h:50:6: warning: ‘__nothrow__’ attribute ignored
string.h:57:14: error: storage class specified for parameter ‘memccpy’
string.h:59:6: warning: ‘__nothrow__’ attribute ignored
...
vt.c:28:1: warning: empty declaration
vt.c:41:1: warning: empty declaration
vt.c:50:1: error: parameter ‘maxtextlength’ is initialized
vt.c:70:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
vt.c:123:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
vt.c:158:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
...
vt.c:67:6: error: declaration for parameter ‘clearinputbuffer’ but no such parameter
vt.c:66:6: error: declaration for parameter ‘clrscr’ but no such parameter
vt.c:65:6: error: declaration for parameter ‘testrandom’ but no such parameter
...
string.h:579:14: error: declaration for parameter ‘stpncpy’ but no such parameter
...
ctype.h:268:12: error: declaration for parameter ‘toupper_l’ but no such parameter
...
process.h:45:22: error: declaration for parameter ‘execl’ but no such parameter
vt.c:608:1: error: expected ‘{’ at end of input
make: *** [vt] Error 1

My problem is, as (I'm sure) many have had before: I just want it to compile.

Question 3641178 seems to suggest that the order of the include files is important, but the headers that are giving errors come AFTER all other included files in vt.c.

I have tried installing Open Watcom on Linux, and the provided header files are the same. As far as I know, these are standard header files, and I can think of no reason why they should cause compile errors.

If anyone can shed any light on this, I'd be very grateful. The entire directory can be accessed in my git repo at git@github.com:megamasha/Vocab-Tester.git ( https://github.com/megamasha/Vocab-Tester )

Answer 1

Your process.h , string.h , ... come from a specific compiler (watcom) and contain compiler-specific keywords (eg __declspec ) that are not supported by gcc (the compiler usually used on Linux).

As far as string.h and ctype.h are concerned, you should remove them completely from your directory and #include them with angular brackets ( <...> ): they are standard headers and each compiler provide its versions (that are compatible with what the standard says).

With process.h , the situation is a bit more difficult, since it's a nonstandard header. Still, as far as I see, process.h seems to contain just some functions that are used to spawn processes, and, from a quick look, it seems that your application doesn't need it; if so, just remove process.h and the relative #include . Otherwise, tell me in the comment, probably there's a quick standard (or OS-specific, but not compiler-specific) replacement.