Re: [gobo-eiffel-develop] Expanded types cause error in generated C code

[Wolfgang J. <wj...@so...>]

Eric Bezault wrote:
> Hi Wolfgang,
>
> Wolfgang Jansen wrote:
>> when experimenting with the "gec" it happened
>> that C compilation failed if the Eiffel code contains
>> entities of expanded types.
>> There are two kinds or errors:
>> - wrong arrangement of type definitions in the *.h file
>> - bad initializer of local variables
>> (0 when a struct is expected)
>>
>> I tried several modifications of routine
>> `ET_C_GENERATOR.print_types' to rearrange type definitions
>> and achieved improvements but no satisfying solution.
>
> Unfortunately expanded types are not supported yet:
>
>    http://www.gobosoft.com/eiffel/gobo/gec/limitations.html
>
> Even after modifying ET_C_GENERATOR.print_types to make it
> work, I'm pretty sure that there would be other glitches
> when there are special Eiffel validity rules or semantics
> for expanded types.
>
>> Probably, the routine must follow the graph of client
>> relations (at least the subgraph of attribute relations)
>> such that the "typedef" declarations are written
>> in the pre-processing phase (to have the corresponding
>> _pointer_ types defined in case of a cyclic dependency)
>> whereas the "struct ..." definitions are written in
>> the post-processing phase (when all attribute types
>> have been processed).
>
> Isn't it what ET_C_GENERATOR.print_types already does?
>
Not yet. The routine does not follow the client relations
but traverses the types by increasing type numbers.
In case of the first written "typedef"s the effect is the
same as what I inteded by "pre-processing".
The bug is that the "struct" of the expanded attribute
is written after the "struct" of its enclosing class
(the post-processing rule would reverse them).
This is caused by the type numbers which have been
associated somewhere else during compilation.
To be precise, I conjecture that the type numbers are
associated in pre-processing manner (and then increasing
type numbers reflect the pre-processing) when the compiler
follows the client relations during program analysis.
If this is so then the actual routine "print_types"
makes pre-processing, not post-processing.

-- 
Wolfgang Jansen
University of Potsdam, Germany
mailto: wj...@so...