> The _size member is the size of the object; for polymorphic objects
> the size isn't known at compile time, so it is to be stored in the
> vtable (in principle, since the vtable tells the exact class of a
> polymorphic object, it should be possible to figure out the size
> without an explicit _size member, but I'll let the OOP experts handle
> that, if they want). There is another vtable member _len which is used
> for character lengths, and that is indeed of type
> gfc_charlen_type_node.
Understood, thanks.
> I think when the dust settles, I might make sense to get rid of
> gfc_charlen_type_node/gfc_charlen_type and just use
> size_type_node/size_t also for string lengths, but at least for now I
> think it's clearer to use separate names.
I agree with keeping them for now.
> So strictly speaking it's not necessary, as long as
> gfc_charlen_type_node is a signed integer.
>
> OTOH, if/when one wants to make gfc_charlen_type_node unsigned,
> perhaps some more far-reaching changes are needed and that work is not
> necessary anymore. Say, introducing BT_UNSIGNED_INTEGER (??) and
> teaching gfc_typespec to handle unsigned integers? Or maybe it's
> better to put a tree node specifying the type in the typespec and use
> that instead of the bt type + kind to tell what type it is?
>
> Do you want me to remove that for the time being?
Let’s remove that, at least for now.
>> There are other cases (resolve.c, simplify.c) where you introduce a
>> dependency on middle-end entities (tree.h, trans-types.h) in what are pure
>> Fortran front-end stages. This breaks the separation that currently exists,
>> and which I strongly think we should keep.
>
> These changes are similar to the above, i.e. a check that uses
> get_type_static_bounds() and works also if gfc_charlen_type_node is
> changed to be an unsigned type.
OK then let’s remove them too.
> - Should I remove the so-far preliminary work to handle
> gfc_charlen_type_node being unsigned?
I think it makes more sense.
> - Should I fix the uses of mpz_{get,set}_{s,u}i?
I think so, otherwise there is little reason to break the ABI and not support
long strings :)
>> - trans-types.h: why do we now need to include trans.h?
>
> IIRC this was due to some of the new .c files including trans-types.h
> but not trans.h and failing to compile. AFAIU the convention is that
> headers should include whatever is necessary to use said header. So
> this is some latent bug that has been exposed by my other changes.
If, with the final version of the patch, you can remove it, please do. And if
you don’t, please remove the trans.h includes from source files that already
include trans-types.h
FX
