Send fpc-pascal mailing list submissions to
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
or, via email, send a message with subject or body 'help' to
You can reach the person managing the list at
When replying, please edit your Subject line so it is more specific
than "Re: Contents of fpc-pascal digest..."
Today's Topics:
1. Re: fpc isn't optimised for tail recursion, is it?
(Jean SUZINEAU)
2. Re: Free Pascal bindings for EyeLink C code (with a
god-cast) (Rafael Pican?o)
3. Re: Free Pascal bindings for EyeLink C code (with a
god-cast) (Marco van de Voort)
4. Re: Non-initialized member access warning (Hairy Pixels)
----------------------------------------------------------------------
Message: 1
Date: Tue, 13 Jun 2023 15:25:59 +0200
From: Jean SUZINEAU
To:
Subject: Re: [fpc-pascal] fpc isn't optimised for tail recursion, is
it?
Message-ID:
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Le 12/06/2023 ? 19:05, Steve Litt via fpc-pascal a ?crit?:
> Busted! I used Pascal 1984-1993
So I guess you are not familiar too with the "Result" variable which
appeared with Delphi 1 in 1995 if I remember correctly.
nextt:= num;
can be written to as :
Result:= num;
https://www.freepascal.org/docs-html/ref/refse94.html
I prefer Result because it reduces risks of confusion with recursive call
and you can eventually take the address of Result with @Result (where
@nextt would take the address of the function nextt),
pass it by reference to another function ( e.g. FillChar( Result,
SizeOf(Result), 0); ) ,
it behaves like a normal variable.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20230613/5a2bb3c5/attachment-0001.htm
>
------------------------------
Message: 2
Date: Tue, 13 Jun 2023 10:38:22 -0300
From: Rafael Pican?o
To:
Subject: Re: [fpc-pascal] Free Pascal bindings for EyeLink C code
(with a god-cast)
Message-ID:
<CAGpuCi5mjRLeCnMY=
>
Content-Type: text/plain; charset="utf-8"
Thank you Marco, I am elaborating on top of your suggestions.
> The problem is that the logical solution, making it a macro, doesn't
work, as macro definitions don't export through USES clauses.
I think that pre-processor constants with $I would be a valid alternative
for using the best solution. For example:
// constants.pp
____
{$MACRO ON}
{$ifndef EXTERNAL_DEV_NONE}
{$DEFINE EXTERNAL_DEV_NONE := TGetExButtonStatesFunction(Pointer(0))}
{$endif}
{$ifndef EXTERNAL_DEV_CEDRUS}
{$DEFINE EXTERNAL_DEV_CEDRUS := TGetExButtonStatesFunction(Pointer(1))}
{$endif}
{$ifndef EXTERNAL_DEV_SYS_KEYBOARD}
{$DEFINE EXTERNAL_DEV_SYS_KEYBOARD :=
TGetExButtonStatesFunction(Pointer(2))}
{$endif}
____
program godcastsucks;
{$I constants}
type
PCCDBS = ^TCCDBS;
TCCDBS = record
userdata: Pointer;
buttons: array[0..255] of AnsiChar;
internal: Pointer;
end;
TGetExButtonStatesFunction = function (accdbs: PCCDBS): Int32; cdecl;
function enable_external_calibration_device(
buttonStatesfcn: Pointer {other arguments removed for simplicity}):
Int32; cdecl;
var
Statesfcn : TGetExButtonStatesFunction;
begin
Result := Int32(TGetExButtonStatesFunction(@buttonStatesfcn^));
case Result of
0 : { do nothing };
else
begin
Statesfcn := TGetExButtonStatesFunction(buttonStatesfcn);
Statesfcn(nil);
Result := -1;
end;
end;
end;
function ExButtonStatesFunction(accdbs: PCCDBS): Int32; cdecl;
begin
WriteLn('God casts sucks');
end;
begin
WriteLn(enable_external_calibration_device(EXTERNAL_DEV_NONE));
WriteLn(enable_external_calibration_device(@ExButtonStatesFunction));
ReadLn;
end.
____
> Note that an alternative for this macro exists since FPC 3.2.0:
Thank you for the reference!
On Tue, Jun 13, 2023 at 7:00?AM
wrote:
> Send fpc-pascal mailing list submissions to
>
>
> To subscribe or unsubscribe via the World Wide Web, visit
>
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
> or, via email, send a message with subject or body 'help' to
>
>
> You can reach the person managing the list at
>
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of fpc-pascal digest..."
>
>
> Today's Topics:
>
> 1. Re: Free Pascal bindings for EyeLink C code (with a
> god-cast) (Marco van de Voort)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 13 Jun 2023 11:25:13 +0200
> From: Marco van de Voort
> To:
> Subject: Re: [fpc-pascal] Free Pascal bindings for EyeLink C code
> (with a god-cast)
> Message-ID:
>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
>
> On 13-6-2023 05:19, Rafael Pican?o via fpc-pascal wrote:
> > (1) I have no idea on how to translate these god-casts, eg.,
> > ((getExButtonStates)0), to free pascal. Right now, I think that even
> > if I don't really need them, I just want?to understand and learn
> > in?the?process.
>
> The problem is that the logical solution, making it a macro, doesn't
> work, as macro definitions don't export through USES clauses.
>
> Defining it a proper constant would be the best solution, but FPC
> doesn't like it :
>
> const
>
> ?EXTERNAL_DEV_NONE = TGetExButtonStatesFunction(pointer(0));
>
> so the next best is turning it into a type constant at the expense of
> sizeof(pointer) bytes in the binary:
>
> const
>
> ? EXTERNAL_DEV_NONE : TGetExButtonStatesFunction= pointer(0);
>
> etc etc.
>
> >
> > (2) So, the whole point here is?binding the
> > "enable_external_calibration_device" function. It expects a
> > "getExButtonStates buttonStatesfcn". Can you check if my current
> > binding is right?
> >
> A purist would say it needs to be "ansichar" rather than char (because
> in future unicode modes char could be 2-byte, for the rest it seems ok.
>
> > (3) I am using the?ELCALLTYPE?macro just because?they were?using them
> > too,?I am assuming backward compatibility. But I am not sure if I
> > really need them. EyeLink code depends on custom SDL2 headers and I
> > am?running SDL2 Free Pascal related stuff just fine (and it has cdecl
> > in everything). What do you think about that? For reference, this is
> > the macro:
> >
> You must match the calling convention of the implementation. Some
> functions have target dependent calling conventions, some non native
> libraries force cdecl even on Windows. (where stdcall or fastcall is
> more conventional)
>
> Note that an alternative for this macro exists since FPC 3.2.0:
>
>
>
https://wiki.freepascal.org/FPC_New_Features_3.2.0#Support_for_WinAPI_directive
>
> Even though the naming is not "elegant" for crossplatform usage.
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> fpc-pascal maillist -
>
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
>
> ------------------------------
>
> End of fpc-pascal Digest, Vol 228, Issue 14
> *******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20230613/59aaf75a/attachment-0001.htm
>
------------------------------
Message: 3
Date: Tue, 13 Jun 2023 15:48:36 +0200
From: Marco van de Voort
To:
Subject: Re: [fpc-pascal] Free Pascal bindings for EyeLink C code
(with a god-cast)
Message-ID:
Content-Type: text/plain; charset=UTF-8; format=flowed
On 13-6-2023 15:38, Rafael Pican?o via fpc-pascal wrote:
> Thank you Marco, I am elaborating on top of your suggestions.
>
> > The problem is that the logical solution, making it a macro, doesn't
> work, as macro definitions don't export through USES clauses.
>
> I think that pre-processor constants with $I would be a valid
> alternative for using the best solution. For example:
>
A matter of taste. I would have as less macros as possible. Moreover the
typed const doesn't require including additional files at the usage
site, so IMHO it is objectively a better solution
------------------------------
Message: 4
Date: Wed, 14 Jun 2023 13:50:34 +0700
From: Hairy Pixels
To: Sven Barth
Cc: FPC-Pascal users discussions
Subject: Re: [fpc-pascal] Non-initialized member access warning
Message-ID:
Content-Type: text/plain; charset=us-ascii
> On Jun 8, 2023, at 6:01 PM, Sven Barth
wrote:
>
> Please report a bug with a complete example.
Better late than never :)
https://gitlab.com/freepascal.org/fpc/source/-/issues/40321
Regards,
Ryan Joseph
------------------------------
Subject: Digest Footer
_______________________________________________
fpc-pascal maillist -
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
------------------------------
End of fpc-pascal Digest, Vol 228, Issue 15
*******************************************
