Thread: reference to undefined macro _MSC_VER
<server/c.h> (a file that gets included in a user's server extension compilation) contains the line # if _MSC_VER > 1400 In the compiler is not Microsoft C at all, _MSC_VER is undefined, and in some environments, the reference to it is an error (e.g. Gcc with -Wundef -Werror). So that this header file can work in all environments, it should have an #ifdef. I see this in Postgres 8.4.3. -- Bryan Henderson San Jose, California
bryanh@giraffe-data.com (Bryan Henderson) writes:
> <server/c.h> (a file that gets included in a user's server extension
> compilation) contains the line
> # if _MSC_VER > 1400
> In the compiler is not Microsoft C at all, _MSC_VER is undefined, and in some
> environments, the reference to it is an error (e.g. Gcc with -Wundef -Werror).
I can't get terribly excited about that. The behavior is perfectly well
defined, and has been clearly specified since K&R C, so making it an
error seems well outside the charter of any compilation environment.
As for -Wundef, it seems rather impractical to turn that on anyway given
that it produces numerous other warnings --- a quick check in HEAD shows
1 be-fsstubs.c:104:5: warning: "FSDB" is not defined
1 be-fsstubs.c:114:5: warning: "FSDB" is not defined
1 be-fsstubs.c:135:5: warning: "FSDB" is not defined
1 bootparse.c:310:6: warning: "YYENABLE_NLS" is not defined
1 bootparse.c:795:6: warning: "YYLTYPE_IS_TRIVIAL" is not defined
1 dynahash.c:183:5: warning: "HASH_STATISTICS" is not defined
1 dynahash.c:588:5: warning: "HASH_DEBUG" is not defined
1 dynahash.c:715:5: warning: "HASH_STATISTICS" is not defined
1 dynahash.c:815:5: warning: "HASH_STATISTICS" is not defined
1 dynahash.c:849:5: warning: "HASH_STATISTICS" is not defined
1 gram.c:16983:6: warning: "YYLTYPE_IS_TRIVIAL" is not defined
1 gram.c:17572:5: warning: "YYLTYPE_IS_TRIVIAL" is not defined
1 gram.c:780:6: warning: "YYENABLE_NLS" is not defined
1 pl_gram.c:1179:6: warning: "YYLTYPE_IS_TRIVIAL" is not defined
1 pl_gram.c:1763:5: warning: "YYLTYPE_IS_TRIVIAL" is not defined
1 pl_gram.c:446:6: warning: "YYENABLE_NLS" is not defined
1 preproc.c:1160:6: warning: "YYENABLE_NLS" is not defined
We could get rid of some of these but the YY ones are generated by
flex and would probably be difficult to prevent.
Personally what I'd like is to see that chunk of code go away from
c.h altogether --- it ought to live in port/win32.h --- which would
alleviate your concern too. But it would take a bit of refactoring of
win32.h.
regards, tom lane
>As for -Wundef, it seems rather impractical to turn that on anyway given >that it produces numerous other warnings --- a quick check in HEAD shows It looks like my point was missed. I'm talking about compiling user code that interfaces with Postgres. I'm specifically talking about server extensions, so it _is_ sort of part of Postgres and some restrictions make sense. But it's compiled outside of the Postgres build, and that makes a big difference. Often, the point of a C-language extension is to bridge between Postgres and some other world, so Postgres can't completely command the compilation (or runtime) environment -- the extension has to meet the requirements of the other world as well. After I added an #ifdef, none of my server extensions encountered an undefined macro warning, so it does help. Incidentally, for those who have never used -Wundef: It's extremely productive. We've all lost way too much time on bugs that happen because in the tangle header files, ifdefs, and source code updates, we forget to define a macro. That's why all of my code is designed to use #if instead of #ifdef and compile with -Wundef -Werror. I find it so valuable that I even maintain workarounds and local patches of other people's interface header files (e.g. Postgres c.h) to allow me to use it. Of course, it would be better still if Postgres came to me already compatible with this style of development. >I can't get terribly excited about that. The thing is, you don't have to get terribly excited. Just slightly interested. Because it just takes two lines of code with zero chance of messing up anything to provide something with a practical use that makes logical sense as well. -- Bryan Henderson San Jose, California