[fpc-devel] Current state of atari port

Sven Barth pascaldragon at googlemail.com
Thu Feb 10 14:21:54 CET 2022

Thorsten Otto via fpc-devel <fpc-devel at lists.freepascal.org> schrieb am
Do., 10. Feb. 2022, 13:00:

> - when constructing objects, ObjectGEM uses contructs like
> new(PGroupBox, init(...)
> Such constructs are not supported by FreePascal, you have to assign the
> result to some variable (i think that is also an incompatibility to
> TurboPascal)

Assuming PGroupbox is declared as a pointer type to some object type it
must either be

GroupBoxPtr := New(PGroupbox, init(...))


New(GroupBoxPtr, init(...))

Anything else does not make sense.

Cause in the variant you mentioned where would the allocated memory be

And yes, FPC is TP compatible here.

 - in a few places i got some strange warnings. For example the code
> var tg,mo,jr: word;
> tsetdate(((jr-1980) shl 9) or (mo shl 5) or tg);
> Gives:
> Hint: (4035) Mixing signed expressions and longwords gives a 64bit result
> I have no idea why calculations with word (16bit) should give a 64bit
> result?

As the m68k port is a 32-bit one all (intermediate) calculations will be
done in the native width (which is 32-bit). And if you have a
signed/unsigned conflict it will escalate to the next width (which is

>  - ObjectGEM uses the type "integer" for all vdi/aes parameters. Since
> that might be some implementation specific size, i started to replace it in
> a few places by "smallint", and doing a "type smallint = integer;" because
> PurePascal does not know that type. That turned out to be not so a good
> idea: although the types are identical, using "smallint" in the interface
> part and "integer" in the implementation is happily accepted by FreePascal,
> but PurePascal complains about a mismatch.

As long as you don't use mode Delphi or mode ObjFPC "Integer" is an alias
to "SmallInt". And as you don't need any Object Pascal functionality in
those units you don't need to enable it.

And for users of the unit it's not relevant. They either need to use the
correct type or the compiler will enforce the type conversion when calling
functions anyway.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20220210/9b0aac55/attachment.htm>

More information about the fpc-devel mailing list