bug#14409: emacs 24.3 -- windows

[Eli Zaretskii <eliz@gnu.org>]

[Please keep the bug address on the CC list.]

> Date: Thu, 16 May 2013 10:45:44 -0400
> From: Frank P Esposito <fpesposito@gmail.com>
> 
> There is an option for MS C   “/P” which will save the pre-processor output
> to a “*.i” file –
> When I open the *.i file, – I think it was actually in the codeset.i file
> – there were lines of expanded macros – so what I included in the email
> probable was not all the expanded code –

I guess you mean charset.i.  Anyway, I will need your help with
finding out what exactly causes Studio 2003 to fail, as I don't have
that installed.  Please find out what part of the macro-expanded
source causes trouble and post it here.

> As noted, Its not clear to me how this would be any faster than using
> inline functions if supported by the compiler — as to the error  – are the
> later version of MS/C compilers support this level of open  parentheses?

Evidently, yes, because a couple of people who regularly build Emacs
with newer versions of MSVC didn't complain.

> I found a reference to SIZE_MAX which is defined in stdint.h (C99) and I
> see that the stdint.h in the nt section does not have this define.

I now added SIZE_MAX to nt/inc/stdint.h.

> It is not clear to me the best way to handle the macros.  The tedious part
> if trying to figure out the data type of the variables not defined in the
> macro

Why is the data type important?

> – what is the thinking for making loops in the form
> 
> do { ...... } while(0)
> 
> why not just { .... }

Because the former can be followed by a semi-colon in any context,
like in an if or a while, while the latter will cause compilation
errors.

> There was an issue with linking – I had to set USE_CRT_DLL=0 then the test
> for this in the make file was incorrect (nmake.defs line 119)  – I was
> missing the $ before the name for the test

Please tell the details about this, I don't think I understand
completely what was the problem.