Martin Storsjö <[email protected]> writes:

> On Thu, 28 Jun 2012, Måns Rullgård wrote:
>
>> Martin Storsjö <[email protected]> writes:
>>
>>> On Thu, 28 Jun 2012, Måns Rullgård wrote:
>>>
>>>>> Replacing restrict with av_restrict fundamentally doesn't seem worse
>>>>> then any of these other restrictions.
>>>>
>>>> This is fundamentally different because it changes the allowed syntax
>>>> from C99 to something slightly different.  Such a change puts an
>>>> additional burden on *all* developers to learn and remember to use the
>>>> modified syntax.
>>>>
>>>> I can think of a number of ways to get around the restrict problem in a
>>>> cleaner way.  Here are two suggestions:
>>>>
>>>> 1. Compile with -Drestrict=__restrict and wrap stdlib.h (apparently the
>>>>   only msvc header that breaks from this) like this:
>>>>
>>>>   #define __restrict restrict
>>>>   #include "c:/path/to/real/stdlib.h"
>>>>   #undef __restrict
>>>>
>>>>   The apparent macro loop is not a problem since the preprocessor only
>>>>   expands each macro once per token.  The wrapper can be generated with
>>>>   the correct path by configure.
>>>>
>>>> 2. Use the preprocessor which is anyway required to replace restrict
>>>>   with __restrict.
>>>>
>>>> Both of these options keep the solution where it belongs, close to the
>>>> problem, rather than broadly infecting all the source code.
>>>
>>> A third one, which I have tested only partially yet, would be to add a
>>> CPPFLAGS that forces including stdlib.h, which would make sure it's
>>> included before our redefinition. Not sure if you find that better or
>>> worse than the other ones though.
>>
>> This would preclude use of restrict in public headers (these cannot
>> include config.h) as well as require including config.h in every file
>> using restrict even if not otherwise necessary.
>
> Well, we don't use it in public headers right now, and I think the
> current usage of config.h more or less covers all places where
> restrict keywords are used. When thinking further about how to solve
> it more completely, I'm ending up with something more or less similar
> to your suggestion #1 (e.g. another header, explicitly included by the
> analogue to --include, which first includes stdlib.h and then defines
> restrict=__restrict).

That would work too of course.

-- 
Måns Rullgård
[email protected]
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to