Hi, On Sat, Jun 16, 2012 at 1:17 AM, Kostya Shishkov <[email protected]> wrote: > On Sat, Jun 16, 2012 at 01:10:15AM -0400, Ronald S. Bultje wrote: >> 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.
Works for me, and what about restrict? Ronald _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
