Hi Eliot,

Monty's implementation considered a conversion to Boolean from int. That got me thinking to provide a definition language that is comparable with the one for external structures. Something like this:

<ffiVariable: #USE_X type: 'long' convertTo: #Boolean>

Yet, I think that such a constant is only useful for tooling in the image because it is not meant to be combined as a bit field.

Best,
Marcel
Am 02.06.2020 20:46:53 schrieb Eliot Miranda <eliot.miranda at gmail.com>:
Hi Marcel,



On May 29, 2020, at 4:40 AM, Marcel Taeumel <marcel.taeumel at hpi.de> wrote:



My bad. Of course, we write 'longlong' and not 'long long' in the definition of external structures.

Still, that question of constency is still valid. 

(Even though ExternalType has not yet support for generating the C type cast yet.)

Best,
Marcel
Am 29.05.2020 13:06:24 schrieb Marcel Taeumel <marcel.taeumel at hpi.de>:
Hi, there!

Here is a question of consistency. :-)

In the definition of external structures, we write 'long' or 'long long'.
In the definition of external pools, we write #Integer.

The latter is automatically converted into a "(long long)" cast for printf.

What is the better approach? I think it would be better to also write 'long' or 'long long' when defining external pools:

<ffiVariable: MY_CONSTANT type: 'long long'>
instead of
<ffiVariable: MY_CONSTANT type: #LargePositiveInteger>


Would make it easier to define platform-specific differences.


IIRC the C standard is clear on the types of integer constants.  A plain constant has type int.  A constant with a single L at the end has type long and one with LL at the end has type long long. UL and ULL suffixes give unsigned long and unsigned long long.  So and generated program to yield the values should yield both the integer value and the strong representation of the value and tndd the type should be inferred from that.

Best,
Marcel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200602/f1bcfec9/attachment.html>