http-parser compiles on MSVS already so I'm not sure why we need these fixes.

http-parser doesn't have anything to do with Ruby. Including ruby/config.h it is not allowed.

Hi ry,

Sorry on the ruby/config.h, I was actually using http-parser.rb which pulls http-parser as git module and didn't realize http-parser wasn't ruby related. Anyway, the issue still remains there that MSVC 2010 does have stdint.h (that is new as of VC 2010) and that conflicts with the code in http_parser.h because the same types get defined twice and you end up with things like typedef int8_t int8_t which isn't allowed. The top of that header looks like this:

/* stdint.h standard header */
#pragma once
#ifndef _STDINT
#define _STDINT

So what I should have done is add a check for defined?(_STDINT) - sorry for the mistake there.

As far as compiling, I'm suprised it works for you. MSVC follows the C rule that you have to declare a variable at the top of a block. Its a gcc extension to not allow that, which I believe is turned off by using the -pedantic flag.

Reading here:

http://stackoverflow.com/questions/6754126/msvc-vs-gcc-variable-declaration-in-function

It looks like you can tell MSVC to compile C files as CPP files, but that could lead to other issues.

So - I'm curious how you are getting this to compile on MSVC. Are you using that flag or some other approach? Because by default it doesn't.

Thanks - Charlie

i just tried it - seemed to work... have you generated your MSVS project with the included .gyp file?

Hi Ry,

No - its being pulled in via http_parser.rb and then being built via nmake. I'll try generating the MSVC project file from the .gyp file and see what it does differently.

Note the stdint.h issue only comes into play if somewhere else in your code you require it...so in general you would not see it.

It looks like you can tell MSVC to compile C files as CPP files, but that could lead to other issues.

The flag you mean is /TP and using it, MSVC 2010 compiles http_parser.c without any warning or error

Yup, that explains that. So by default VC assumes a ".c" file is c an enforces C89 rules. /TP tells VC to compile all files as C++, which solves the variable issue.

Don't know if that introduces other isssues or not. One thing I can think of off the top of my head is if someone includes the file in their library and builds a dll, the names will then have C++ mangling. You can of course work around that, but is an extra thing to worry about.

Note that gcc won't work either if you use the --pedantic flag.

Anyway, thanks for looking at this.