Re: reference to undefined macro _MSC_VER

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