Re: Graphite header order

[David Edelsohn <dje dot gcc at gmail dot com>]

On Fri, Nov 20, 2015 at 11:28 AM, Sebastian Pop <sebpop@gmail.com> wrote:
> Thanks David for reporting these problems.
>
> On Fri, Nov 20, 2015 at 9:31 AM, David Edelsohn <dje.gcc@gmail.com> wrote:
>> (2) All of the graphite*.c files include ISL headers first.  This
>> order is not supported by GCC development and creates conflicts for
>> types and definitions provided / overridden by GCC headers, especially
>> system.h and its dependent headers like hwint.h.
>>
>> I presume that ISL headers are included first is they use calloc() and
>> strdup(), which are poisoned by GCC in system.h.
>
> Yes, I do remember we had problems including the isl headers after system.h.
>
>>
>> I am uncertain of the exact header dependencies, but the primary
>> dependency seems to be that the ISL headers must be included before
>> graphite-poly.h.  The identifier poisoning problem needs to be
>> addressed by not poisoning the identifiers for files that include ISL
>> headers.  The Graphite files need some sort of a macro like
>>
>> #define IN_GRAPHITE
>>
>> or
>>
>> #define IN_ISL
>>
>> and system.h must not poison the identifiers when that macro is present.
>>
>> I am going to try with a hack of bracketing system.h with #undef
>> IN_GCC / #define IN_GCC in the graphite files.
>
> I don't understand why these symbols are poisoned in GCC.
> If there is a good reason to poison these functions, why would they
> be fine to be used in Graphite and ISL?
>
> Would it be possible to relax these constraints and remove the
> poisoning of these functions in GCC?

GCC should use xmalloc, xcalloc, xstrdup, etc.

https://gcc.gnu.org/ml/gcc-patches/2001-03/msg00484.html

We cannot change ISL, so the poisoning should be lifted for those
files instead of including headers in the wrong order.

GCC similarly removes the restrictions for Flex and Bison.

- David