> 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 <[email protected]> > 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!
