On Sat, Jun 16, 2012 at 01:10:15AM -0400, Ronald S. Bultje wrote:
> Hi,
> 
> On Sat, Jun 16, 2012 at 12:58 AM, Kostya Shishkov
> <[email protected]> wrote:
> > On Sat, Jun 16, 2012 at 12:41:35AM -0400, Ronald S. Bultje wrote:
> >> On Sat, Jun 16, 2012 at 12:39 AM, Kostya Shishkov
> >> <[email protected]> wrote:
> >> > On Fri, Jun 15, 2012 at 06:02:11PM -0700, Ronald S. Bultje wrote:
> >> >> On Fri, Jun 15, 2012 at 5:41 PM, Måns Rullgård <[email protected]> wrote:
> >> >> > "Ronald S. Bultje" <[email protected]> writes:
> >> >> >
> >> >> >> From: "Ronald S. Bultje" <[email protected]>
> >> >> >>
> >> >> >> Defining restrict results - for some compilers - in changing other
> >> >> >> uses of the restrict keyword also, e.g. __declspec(restrict) gets
> >> >> >> changed to __declspec(__restrict) on MSVC. This causes compilation
> >> >> >> failures. Therefore, using a private namespace macro instead is
> >> >> >> more reliable and robust.
> >> >> >
> >> >> > NAK.  restrict is a C99 keyword, and we use C99 features all over the
> >> >> > place.  Whatever preprocessor is used to handle, for instance,
> >> >> > designated initialisers can just as easily handle these keywords.
> >> >>
> >> >> By which law were we decreed that c99 shall be the end of the world? I
> >> >> wish to support a compiler that does not support c99. Shall we work
> >> >> together and make that happen or shall we just cry like little zealous
> >> >> babies while the real world passes by?
> >> >
> >> > Damn, you said your preprocessor is for converting C99 to C89.
> >> > So just remove that keyword in it. It's only a hint for compiler after 
> >> > all.
> >>
> >> This does not belong in the preprocessor.
> >
> > Why?
> 
> The preprocessor is for:
> 
> { .x = y } -> { y }
> [x] = y -> y
> (x) { y, z } -> { y, z } or val.v=y; val.w=z; or something like that
> 
> Random other crap that can is in any other case handled by configure
> should be handled by configure in this case as well. I'm looking to
> make MSVC a real supported platform, not some hack with tons of
> outside work. That's pointless and will die before anything.
> 
> Again: are we in to make this happen or not?

As you said - not some hack.
And some things that are MSVC-specific should be handled by it and not as an
internal hack. An example: just pass compiler flags to define "inline" to
"__inline" as other projects do.
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to