gobo-eiffel-develop

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

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

Hi,

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.
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).

PS:
The attachment contains the Eiffel classes of an example,
an ACE file, and the compiler messages (for both, "cc" and "gcc").

PPS:
Maybe you got this message a second time: I sent it a second time
since the mail server told me that the original message had not been 
delivered.

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

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

[Eric B. <er...@go...>]

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?

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

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...

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

[Eric B. <er...@go...>]

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 fixed both problems. Well, at least the example you
sent me now compiles. But be prepared for other glitches
with expanded types. For example not all validity rules for
expanded types are checked, `default_create' is not called
on new objects and `copy' is not called in assignments
(which might be OK as long as `default_create' and `copy'
have not been redefined). Arrays of expanded items might
have problems as well.

If you want to try the new version, you will have to get
it from SVN. I don't know if you're familiar with the bootstrap
mechanism of Gobo. You first have to get a fresh copy from SVN, and
then follow the instructions in $GOBO/work/bootstrap/Readme.txt.
For your convenience I've added 'cc' to the list of supported
C compiler here as well.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com