Re: [libav-devel] [PATCH] Support for MSVC.
On Thu, Jun 14, 2012 at 1:59 AM, Ronald S. Bultje wrote: > Hi, > > see attached. It's kinda big, some parts can/should be done > differently, but it's a starting point so let's start talking about > how to get this in the right way. > > Some general comments: > - only tested on 32bit so far > - no it won't compile on non-MSVC with my patch (I had to break the > Makefile in a couple of places to get linking to work) > - the include of stdlib.h everywhere is because of [1]. We may need to > add av_restrict instead. > - the include of mathematics.h, avconfig.h and avstring.h everywhere > is (I think) legit, to account for snprintf(), M_PI or inline. > - the added assembly in fmtconvert.asm helps to get rid of a VLA in > fmtconvert_mmx.c. > - test.c converts c99 to c89 which MSVC can compile. Don't look at it > unless you want to see true pain, it's intended to be shipped outside, > like gas-preprocessor.pl. (unit.c and unit2.c are unittests for it.) > - the renames of libavutil/x86/cpu.c, libavcodec/x86/mlpdsp.c and > libswscale/x86/rgb2rgb.c are to prevent duplicate filenames in the > same library, which makes the MSVC linker crap out in debug mode > (works fine in release mode). > - it mostly passes fate, except zlib-dependent tests (because I didn't > try including zlib yet) and wtv (which uses gmtime(), which is broken > on Windows since it only supports years up to 3000, and our test file > uses 10900.) All other tests pass. > > Ronald > > [1] > http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/bf3c0191-c15d-4e73-a111-3796608900c7 can you provide prebuilt binaries for c99-to-c89.exe for windows? it will make using it that much easier -- Aviad Rozenhek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] Support for MSVC.
Hi, On Tue, Oct 9, 2012 at 10:33 AM, aviad rozenhek wrote: > > On Thu, Jun 14, 2012 at 1:59 AM, Ronald S. Bultje > wrote: >> >> Hi, >> >> see attached. It's kinda big, some parts can/should be done >> differently, but it's a starting point so let's start talking about >> how to get this in the right way. >> >> Some general comments: >> - only tested on 32bit so far >> - no it won't compile on non-MSVC with my patch (I had to break the >> Makefile in a couple of places to get linking to work) >> - the include of stdlib.h everywhere is because of [1]. We may need to >> add av_restrict instead. >> - the include of mathematics.h, avconfig.h and avstring.h everywhere >> is (I think) legit, to account for snprintf(), M_PI or inline. >> - the added assembly in fmtconvert.asm helps to get rid of a VLA in >> fmtconvert_mmx.c. >> - test.c converts c99 to c89 which MSVC can compile. Don't look at it >> unless you want to see true pain, it's intended to be shipped outside, >> like gas-preprocessor.pl. (unit.c and unit2.c are unittests for it.) >> - the renames of libavutil/x86/cpu.c, libavcodec/x86/mlpdsp.c and >> libswscale/x86/rgb2rgb.c are to prevent duplicate filenames in the >> same library, which makes the MSVC linker crap out in debug mode >> (works fine in release mode). >> - it mostly passes fate, except zlib-dependent tests (because I didn't >> try including zlib yet) and wtv (which uses gmtime(), which is broken >> on Windows since it only supports years up to 3000, and our test file >> uses 10900.) All other tests pass. >> >> Ronald >> >> [1] >> http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/bf3c0191-c15d-4e73-a111-3796608900c7 > > > can you provide prebuilt binaries for c99-to-c89.exe for windows? it will > make using it that much easier https://gerrit.chromium.org/gerrit/#/c/34728/ You'll need c99wrap.exe also, but that one is trivial to build yourself, since it has no dependencies. Ronald ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] Support for MSVC.
On 13/06/2012 7:59 PM, Ronald S. Bultje wrote: > - the include of mathematics.h, avconfig.h and avstring.h everywhere > is (I think) legit, to account for snprintf(), M_PI or inline. We don't need to do this for mathematics.h, as discussed on IRC. If we define _USE_MATH_DEFINES, we have access to teh usual M_PI, etc. in MSVC's math.h. - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] Support for MSVC.
On 13/06/2012 11:40 PM, Derek Buitenhuis wrote: > On 13/06/2012 7:59 PM, Ronald S. Bultje wrote: >> - the include of mathematics.h, avconfig.h and avstring.h everywhere >> is (I think) legit, to account for snprintf(), M_PI or inline. > > We don't need to do this for mathematics.h, as discussed on IRC. > > If we define _USE_MATH_DEFINES, we have access to teh usual M_PI, etc. > in MSVC's math.h. And a followup with: http://msdn.microsoft.com/en-us/library/2ts7cx93%28v=vs.80%29.aspx or http://msdn.microsoft.com/en-us/library/f30dzcf6%28v=vs.80%29.aspx Cheers, - Derek ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] Support for MSVC.
Hi, On Wed, Jun 13, 2012 at 8:40 PM, Derek Buitenhuis wrote: > On 13/06/2012 7:59 PM, Ronald S. Bultje wrote: >> - the include of mathematics.h, avconfig.h and avstring.h everywhere >> is (I think) legit, to account for snprintf(), M_PI or inline. > > We don't need to do this for mathematics.h, as discussed on IRC. > > If we define _USE_MATH_DEFINES, we have access to teh usual M_PI, etc. > in MSVC's math.h. Interesting, hadn't noticed yet. So, we can add this to config.h (if needed), or in mathematics.h (but then we still need all the include modifications). Which one do people prefer? Ronald ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] Support for MSVC.
Hi, On Wed, Jun 13, 2012 at 8:49 PM, Derek Buitenhuis wrote: > On 13/06/2012 11:40 PM, Derek Buitenhuis wrote: >> On 13/06/2012 7:59 PM, Ronald S. Bultje wrote: >>> - the include of mathematics.h, avconfig.h and avstring.h everywhere >>> is (I think) legit, to account for snprintf(), M_PI or inline. >> >> We don't need to do this for mathematics.h, as discussed on IRC. >> >> If we define _USE_MATH_DEFINES, we have access to teh usual M_PI, etc. >> in MSVC's math.h. > > And a followup with: > > http://msdn.microsoft.com/en-us/library/2ts7cx93%28v=vs.80%29.aspx > > or > > http://msdn.microsoft.com/en-us/library/f30dzcf6%28v=vs.80%29.aspx Same here, the snprintf define can go in config.h or avstring.h (and then include that everywhere) - which do people prefer? Ronald ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] Support for MSVC.
On 06/14/2012 06:24 AM, Ronald S. Bultje wrote: > Hi, > > On Wed, Jun 13, 2012 at 8:40 PM, Derek Buitenhuis > wrote: >> On 13/06/2012 7:59 PM, Ronald S. Bultje wrote: >>> - the include of mathematics.h, avconfig.h and avstring.h everywhere >>> is (I think) legit, to account for snprintf(), M_PI or inline. >> >> We don't need to do this for mathematics.h, as discussed on IRC. >> >> If we define _USE_MATH_DEFINES, we have access to teh usual M_PI, etc. >> in MSVC's math.h. > > Interesting, hadn't noticed yet. So, we can add this to config.h (if > needed), or in mathematics.h (but then we still need all the include > modifications). Which one do people prefer? config.h sounds better. lu -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] Support for MSVC.
"Ronald S. Bultje" writes: > Hi, > > see attached. It's kinda big, some parts can/should be done > differently, but it's a starting point so let's start talking about > how to get this in the right way. If you split the patch into logically independent "fixes", reviewing it might be almost possible. As is, I refuse to even begin looking at it. > Some general comments: > - only tested on 32bit so far > - no it won't compile on non-MSVC with my patch (I had to break the > Makefile in a couple of places to get linking to work) That's fine for a work in progress. We can fix it properly later. > - the include of stdlib.h everywhere is because of [1]. We may need to > add av_restrict instead. I fail to see how that ph0rum post suggests including stdlib.h everywhere. The problem is that msvc doesn't support the restrict keyword. You'll have remove it with a custom preprocessor or something, just like you have to remove designated initialisers. > - the include of mathematics.h, avconfig.h and avstring.h everywhere > is (I think) legit, to account for snprintf(), M_PI or inline. I seriously doubt that those are really needed in all the places you've added them. > - the added assembly in fmtconvert.asm helps to get rid of a VLA in > fmtconvert_mmx.c. Please submit that as a separate patch. It's a good thing on its own. > - test.c converts c99 to c89 which MSVC can compile. Don't look at it > unless you want to see true pain, it's intended to be shipped outside, > like gas-preprocessor.pl. (unit.c and unit2.c are unittests for it.) Then please do not include those in the patch. > - the renames of libavutil/x86/cpu.c, libavcodec/x86/mlpdsp.c and > libswscale/x86/rgb2rgb.c are to prevent duplicate filenames in the > same library, which makes the MSVC linker crap out in debug mode > (works fine in release mode). Seriously? -- Måns Rullgård m...@mansr.com ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] Support for MSVC.
"Ronald S. Bultje" writes: > Hi, > > On Wed, Jun 13, 2012 at 8:49 PM, Derek Buitenhuis > wrote: >> On 13/06/2012 11:40 PM, Derek Buitenhuis wrote: >>> On 13/06/2012 7:59 PM, Ronald S. Bultje wrote: - the include of mathematics.h, avconfig.h and avstring.h everywhere is (I think) legit, to account for snprintf(), M_PI or inline. >>> >>> We don't need to do this for mathematics.h, as discussed on IRC. >>> >>> If we define _USE_MATH_DEFINES, we have access to teh usual M_PI, etc. >>> in MSVC's math.h. >> >> And a followup with: >> >> http://msdn.microsoft.com/en-us/library/2ts7cx93%28v=vs.80%29.aspx >> >> or >> >> http://msdn.microsoft.com/en-us/library/f30dzcf6%28v=vs.80%29.aspx > > Same here, the snprintf define can go in config.h or avstring.h (and > then include that everywhere) - which do people prefer? I prefer you do that in your preprocessor. -- Måns Rullgård m...@mansr.com ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] Support for MSVC.
"Ronald S. Bultje" writes: > Hi, > > On Wed, Jun 13, 2012 at 8:40 PM, Derek Buitenhuis > wrote: >> On 13/06/2012 7:59 PM, Ronald S. Bultje wrote: >>> - the include of mathematics.h, avconfig.h and avstring.h everywhere >>> is (I think) legit, to account for snprintf(), M_PI or inline. >> >> We don't need to do this for mathematics.h, as discussed on IRC. >> >> If we define _USE_MATH_DEFINES, we have access to teh usual M_PI, etc. >> in MSVC's math.h. > > Interesting, hadn't noticed yet. So, we can add this to config.h (if > needed), or in mathematics.h (but then we still need all the include > modifications). Which one do people prefer? CFLAGS -- Måns Rullgård m...@mansr.com ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] Support for MSVC.
Hi, On Thu, Jun 14, 2012 at 2:45 AM, Måns Rullgård wrote: > "Ronald S. Bultje" writes: >> - the include of mathematics.h, avconfig.h and avstring.h everywhere >> is (I think) legit, to account for snprintf(), M_PI or inline. > > I seriously doubt that those are really needed in all the places you've > added them. Depends on which one. Each mathematics.h needs them for M_PI or something alike. Now, regardless of whether MSVC has M_PI included, if mathematics.h has a fallback for M_PI where the system does not provide it, we should include mathematics.h where we use M_PI, so these should be legit. avstring.h is for snprintf() which may not be necessary. avconfig.h is for inline which we should probably discuss on its own. Ronald ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] Support for MSVC.
Derek Buitenhuis writes: > On 13/06/2012 11:40 PM, Derek Buitenhuis wrote: >> On 13/06/2012 7:59 PM, Ronald S. Bultje wrote: >>> - the include of mathematics.h, avconfig.h and avstring.h everywhere >>> is (I think) legit, to account for snprintf(), M_PI or inline. >> >> We don't need to do this for mathematics.h, as discussed on IRC. >> >> If we define _USE_MATH_DEFINES, we have access to teh usual M_PI, etc. >> in MSVC's math.h. > > And a followup with: > > http://msdn.microsoft.com/en-us/library/2ts7cx93%28v=vs.80%29.aspx > > or > > http://msdn.microsoft.com/en-us/library/f30dzcf6%28v=vs.80%29.aspx We can't use the Windows _snprintf() since it has the wrong semantics. The standard snprintf() always null-terminates the output and returns the full length of the formatted string. The Windows version does not null-terminate if the buffer fills up and returns a negative value if the formatted string is longer than the buffer. Windows vsnprintf has the same problem, but wrapping this function, it is at least possible to ensure the output is null-terminated. I don't think we rely on the return value to indicate the would-be size of a truncated output. We do, however, use it in ways (x += snprintf()) that would break in case the buffer fills up and the return value is negative because of this. -- Måns Rullgård m...@mansr.com ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
