Re: [PATCH 0/5] Support building bison with MSVC

[Anonymous Maarten]

> Is this really the name I should use to refer to you, in the commit
> messages and in THANKS?

You can use: Maarten De Braekeleer <maarten.debraekeleer@gmail.com>

> Grr.  I'm very unhappy with these constraints.  Where are they coming
> from?  Why don't we get rid of these spurious symbols instead?
>
> For instance in the case of max, NOMINMAX should get rid of it, doesn't it?
> What's the path of inclusion of headers that brings these guys?  Where
> is CHAR coming from?  I guess it's a macro, so we should be able to undef
> it, right?\

I traced the max definition coming from Windows SDK's stdlib.h.
It's not included through windows.h, so NOMINMAX does nothing.
See https://github.com/citra-emu/citra/pull/3773 for somebody else's woes.
The min/max define can be avoided by adding the
`_CRT_DECLARE_NONSTDC_NAMES=0 ` definition.
(Adding the =0 was important for me)
But adding it causes other errors to appear:
`src\location.c(298): error C2065: 'S_IFREG': undeclared identifier`
I didn't check further, because I have no idea how to provide S_IFREG
another way.
So I think that definition should not be added.
I renamed the functions to max_int because there was precedent in
other source files where this was done too.

The CHAR and INT rename fix the following errors:
```
src/parse-gram.h(130): error C2365: 'CHAR': redefinition; previous
definition was 'typedef'
C:\Program Files (x86)\Windows
Kits\10\include\10.0.17763.0\um\winnt.h(431): note: see declaration of
'CHAR'
src/parse-gram.h(130): error C2086: 'gram_tokentype CHAR': redefinition
src/parse-gram.h(130): note: see declaration of 'CHAR'
src/parse-gram.h(143): error C2365: 'INT': redefinition; previous
definition was 'typedef'
C:\Program Files (x86)\Windows
Kits\10\include\10.0.17763.0\shared\minwindef.h(176): note: see
declara
tion of 'INT'
src/parse-gram.h(143): error C2086: 'gram_tokentype INT': redefinition
```
They are typedefs.
I don't see any obvious way to circumvent their definition..

The accept rename is caused by gnulib including winsock.h for
emulating unistd.h.
There are probably other include paths.

> > In the first patch, I hid the inclusion of 2 files behind a macro.
> > I haven't checked whether these missing files can be provided through
> > gnulib.
>
> It appears there is.  I'm looking into this right now.

Thanks!