[tex-live] [Dev-luatex] luatex0.c compile problem
Vladimir Volovich
vvv at vsu.ru
Tue Apr 29 09:05:18 CEST 2008
>> here are the statements on the referenced lines:
>>
>> 8931: eq_destroy ( eqtb [p ]) ;
>> 8940: eq_destroy ( eqtb [p ]) ;
>> 9005: eq_destroy ( eqtb [p ]) ;
>> 9124: eq_destroy ( save_stack [save_ptr ]) ;
>> 9133: eq_destroy ( eqtb [p ]) ;
>>
>> does this make sense to you? eqtb and save_stack is a structure.
>
> It may be complaining about eq_destroy, because these five happen to
> be all the calls to that function. Perhaps it misinterprets the
> macro in luatexcoerce.h. Not that I see a reason why it should,
> this function is converted by web2c just like all others. Or
> perhaps it is mis-optimizing something?
DK> Ancient compilers did not allow for passing structures to
DK> functions. It sounds somewhat unlikely that this would be the only
DK> case here, though.
DK> Maybe a missing prototype or something for eq_destroy?
i investigated it further.
after pre-processing,
eq_destroy ( eqtb [p ]) ;
gets changed to:
zeq_destroy((memoryword) (eqtb [p ])) ;
i.e. the casts are added to the argument.
it appears that the compiler is not happy about the constructs with such
casts, it has nothing to do with the zeq_destroy function itself.
i.e. if i manually remove the casts after passing the code through a
pre-processor, i.e. change it to
zeq_destroy( eqtb [p ]) ;
then it compiles fine.
to see further, i created a small test file:
===================================
typedef struct {
int CINT0, CINT1;
} twoints;
void test (twoints *z) {
twoints v1 = z[0];
twoints v2 = (twoints) (z[0]);
twoints v3 = *z;
twoints v4 = (twoints) (*z);
}
===================================
$ xlc -c test.c
"test.c", line 7.17: 1506-117 (S) Operand must be a scalar type.
"test.c", line 9.17: 1506-117 (S) Operand must be a scalar type.
it gives errors for lines with casts and no errors for lines without
casts.
does that make sense to anyone?
Best,
v.
More information about the tex-live
mailing list