On Sat, Jun 16, 2012 at 01:22:26AM -0400, Ronald S. Bultje wrote: > 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?
The same - you can define it to empty. _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
