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?
Ronald
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
