Hi, On Sat, Jun 16, 2012 at 1:32 AM, Kostya Shishkov <[email protected]> wrote: > On Sat, Jun 16, 2012 at 01:22:26AM -0400, Ronald S. Bultje wrote: >> 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.
No, it's __restrict, not empty, and either way defining it fails because you override __declspec(restrict) (which means noalias) in headers, which causes compile failures (__declspec(__restrict) or __declspec() is invalid). See the other patch description, it's all in there. Ronald _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
