Re: [fpc-pascal] Help with TList example
Two observations:
1. In Pascal you should use "new" and "dispose" to allocate and
deallocate record types - not GetMem and FreeMem.
2. MyRec is a pointer type and you should code the line as
MyRec^.Value := tmp
On 08/09/2020 12:10, James Richters via fpc-pascal wrote:
I'm trying to figure out how TList works. I found the code example below by
doing a search, but I can't compile it, I get Error: Illegal qualifier on the
line
MyRec.Value := tmp;
It's indicating the error is on the V of Value
I tried commenting that line out, then I get the same error on
MyRec.AByte := Byte(tmp);
At the A of AByte
So I commented that out too and then I get the error on
Writeln('Value: ', MyRecList[tmp].Value, ' AByte: ', MyRecList[tmp].AByte);
At the V on Value after MyRecList[tmp].
I don't know enough about the syntax to figure out what's wrong here. Does
anyone have any ideas? It seems like there is something fundamentally wrong.
I'm trying to make a temporary list of records. Kind of like a TStringList,
but instead of a list of strings, a list of my own custom records. Perhaps
there is a better way?
program Project1;
{$mode objfpc}{$H+}
uses
SysUtils, Classes;
type
PMyRec=^TMyRec;
TMyRec=record
Value: Integer;
AByte: Byte;
end;
TMyRecList=class(TList)
private
function Get(Index: Integer): PMyRec;
public
destructor Destroy; override;
function Add(Value: PMyRec): Integer;
property Items[Index: Integer]: PMyRec read Get; default;
end;
{ TMyRecList }
function TMyRecList.Add(Value: PMyRec): Integer;
begin
Result := inherited Add(Value);
end;
destructor TMyRecList.Destroy;
var
i: Integer;
begin
for i := 0 to Count - 1 do
FreeMem(Items[i]);
inherited;
end;
function TMyRecList.Get(Index: Integer): PMyRec;
begin
Result := PMyRec(inherited Get(Index));
end;
var
MyRecList: TMyRecList;
MyRec: pMyRec;
tmp: Integer;
begin
MyRecList := TMyRecList.Create;
for tmp := 0 to 9 do
begin
GetMem(MyRec, SizeOf(TMyRec));
MyRec.Value := tmp;
MyRec.AByte := Byte(tmp);
MyRecList.Add(MyRec);
end;
for tmp := 0 to MyRecList.Count - 1 do
Writeln('Value: ', MyRecList[tmp].Value, ' AByte: ', MyRecList[tmp].AByte);
WriteLn(' Press Enter to free the list');
ReadLn;
MyRecList.Free;
end.
James
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Help with TList example
See https://www.freepascal.org/docs-html/rtl/system/dispose.html
On 08/09/2020 12:51, James Richters wrote:
Can you please give me an example of the correct way to use new and dispose?
I'll try the pointer
Thanks for the advice
James
-Original Message-
From: fpc-pascal On Behalf Of Tony
Whyman via fpc-pascal
Sent: Tuesday, September 8, 2020 7:21 AM
To: fpc-pascal@lists.freepascal.org
Cc: Tony Whyman
Subject: Re: [fpc-pascal] Help with TList example
Two observations:
1. In Pascal you should use "new" and "dispose" to allocate and deallocate
record types - not GetMem and FreeMem.
2. MyRec is a pointer type and you should code the line as
MyRec^.Value := tmp
On 08/09/2020 12:10, James Richters via fpc-pascal wrote:
I'm trying to figure out how TList works. I found the code example below by
doing a search, but I can't compile it, I get Error: Illegal qualifier on the
line
MyRec.Value := tmp;
It's indicating the error is on the V of Value
I tried commenting that line out, then I get the same error on
MyRec.AByte := Byte(tmp);
At the A of AByte
So I commented that out too and then I get the error on
Writeln('Value: ', MyRecList[tmp].Value, ' AByte: ',
MyRecList[tmp].AByte); At the V on Value after MyRecList[tmp].
I don't know enough about the syntax to figure out what's wrong here. Does
anyone have any ideas? It seems like there is something fundamentally wrong.
I'm trying to make a temporary list of records. Kind of like a TStringList,
but instead of a list of strings, a list of my own custom records. Perhaps
there is a better way?
program Project1;
{$mode objfpc}{$H+}
uses
SysUtils, Classes;
type
PMyRec=^TMyRec;
TMyRec=record
Value: Integer;
AByte: Byte;
end;
TMyRecList=class(TList)
private
function Get(Index: Integer): PMyRec;
public
destructor Destroy; override;
function Add(Value: PMyRec): Integer;
property Items[Index: Integer]: PMyRec read Get; default;
end;
{ TMyRecList }
function TMyRecList.Add(Value: PMyRec): Integer; begin
Result := inherited Add(Value);
end;
destructor TMyRecList.Destroy;
var
i: Integer;
begin
for i := 0 to Count - 1 do
FreeMem(Items[i]);
inherited;
end;
function TMyRecList.Get(Index: Integer): PMyRec; begin
Result := PMyRec(inherited Get(Index)); end;
var
MyRecList: TMyRecList;
MyRec: pMyRec;
tmp: Integer;
begin
MyRecList := TMyRecList.Create;
for tmp := 0 to 9 do
begin
GetMem(MyRec, SizeOf(TMyRec));
MyRec.Value := tmp;
MyRec.AByte := Byte(tmp);
MyRecList.Add(MyRec);
end;
for tmp := 0 to MyRecList.Count - 1 do
Writeln('Value: ', MyRecList[tmp].Value, ' AByte: ',
MyRecList[tmp].AByte);
WriteLn(' Press Enter to free the list');
ReadLn;
MyRecList.Free;
end.
James
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpcmake packaging
On 01/09/2020 14:29, Ryan Joseph via fpc-pascal wrote: On Sep 1, 2020, at 7:46 PM, Tony Whyman via fpc-pascal wrote: fpcmake is a pre-processor that generates makefiles for fpc projects. You can use it to do just about anything a standard makefile can do, including including resource files and running scripts. I use it all the time for building production versions of lazarus programs and prior to packaging the programs and resources in .deb and .rpm files. On 01/09/2020 13:37, Ryan Joseph via fpc-pascal wrote: Apparently there is fpmake and fpcmake, which I didn't know. I guess what you're saying is that I start with fpcmake and get makefiles which I can then use to do packing and all the stuff I need? I've thought of using makefiles before but I ran into the problem of have all this logic that I need to duplicate for each project. What I'm really after is something more like lazbuild that takes a config file and does all the commands for you. I guess I could even use lazbuild but again, the packaging doesn't seem possible since lazbuild is so Lazarus focused (obviously). Regards, Ryan Joseph My primary motivation for going with fpcmake is that it is a very good fit with the debian package management system (and rpmbuild). My normal build target is Ubuntu and hence I want to generate .deb files in order to distribute my application. The Debian Package Manager does not actually mandate use of makefiles - but it is built around the makefile concept and I have only ever seen examples of use based on makefiles. I would position fpcmake as similar to autoconf/ automake in the C/C++ work. With automake, you need a Makefile.am in every directory of your project that contains something to compile or include in your package. With fpcmake you need a Makefile.fpc instead. This file contains the directives needed to generate the makefile and looks like an ini file. An example follows taken from a simple application I have for Requirements Management. The Makefile.fpc uses external environment variables, such as "INTERFACE". An external script (or a Debian rules file) that calls "make" itself to compile the project would define export INTERFACE=gtk2 assuming you want gtk2 for your GUI. Otherwise, the [compiler] section defines the fpc options, and directories to search. Most of these are part of my project. I have also used environment variables to define the build target and where to find the lazarus units. The [install] section is where I tell it to install resource files. This includes an icon for the program and Firebird resource files. My project also requires that a .res file is built before the program is linked and there is a [prerules] section for this. "mkversioninfo" is my own utility, which generates the input to the windres utility for .res file generation. Finally, there is an extra [rules] section to ensure that my resources are built when a "make all" is called. [requires] packages=fcl-res libc=y [compiler] options= -MDelphi -Scghi -O3 -CX -Xs -vewnhi -l -dUseCThreads -dLCL -dLCL$(INTERFACE) unittargetdir=units/$(CPU_TARGET)-$(OS_TARGET) includedir=$(LZINCLUDE) unitdir=$(LAZUNITDIR)/* $(LAZUNITDIR)/*/$(INTERFACE) \ ../frames \ ../forms \ ../dlg \ ../reports \ ../ole \ ../ \ . [target] programs=RequirementsManagerPersonal [install] datadir=$(INSTALL_PREFIX)/share/RequirementsManager files=RequirementsManagerPersonal.xpm firebird.conf firebird.msg [prerules] resources: rm -f RequirementsManagerPersonal.res mkversioninfo requirementsmanager-personal RequirementsManager.ico | $(WINDRES) -o RequirementsManagerPersonal.res [rules] all: resources fpc_all A debian rules file for use with fpcmake is usually the same for every fpc project i.e. Note this calls fpcmake automatically. A C/C++ build would call "configure" at the same point. I have defined the INTERFACE as an argument to the call to make. #!/usr/bin/make -f # -*- makefile -*- # Sample debian/rules that uses debhelper. # # This file was originally written by Joey Hess and Craig Small. # As a special exception, when this file is copied by dh-make into a # dh-make output file, you may use that output file without restriction. # This special exception was added by Craig Small in version 0.37 of dh-make. # # Modified to make a template file for a multi-binary package with separated # build-arch and build-indep targets by Bill Allombert 2001 # Uncomment this to turn on verbose mode. export DH_VERBOSE=1 # This has to be exported to make some magic below work. export DH_OPTIONS DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE) DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE) export FPCDIR=/usr/lib/fpc/$(shell fpc -iV) configure: configure-stamp configure-stamp: dh_testdir # Add here commands to configure the package. fpcmake -r Makefile.fpc touc
Re: [fpc-pascal] fpcmake packaging
fpcmake is a pre-processor that generates makefiles for fpc projects. You can use it to do just about anything a standard makefile can do, including including resource files and running scripts. I use it all the time for building production versions of lazarus programs and prior to packaging the programs and resources in .deb and .rpm files. On 01/09/2020 13:37, Ryan Joseph via fpc-pascal wrote: I've never used fpcmake before and instead relied on my own custom build system solutions which are a pain to maintain and non-standard which it makes extra work configuring the pascal language server I'm using now. My first question of fpcmake is, can I package application bundles and copy resources using it? For example some things I need to do: - create a directory structure and copy the executable into it - copy resource files that may have changed - run some shell commands which apple provides for compiling various resources files - copy a info.plist text file and replace some patterns in the file to reflect the build version Are those the kind of things fpcmake can do or do I need another build system for this? Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Sending Hex codes over TCP/IP
A TCP connection is no more than a pair of byte streams - one in each direction. You have to define your own structure for each byte stream and the procedures for use i.e. a protocol. lt will be easier if you can use a standard protocol such as http. An http POST is one way to send an array of bytes to a server and to receive a response. if you want to define your own protocol then you could send your array of bytes as an integer length followed by the bytes encoded one after the other. If you want your protocol to be platform independent then be careful to define the bit order (little endien or big endien) and how multibyte integers are encoded (low order byte first or high order byte first).Your protocol could be as simple as one side iniiates a connection, sends a byte count followed by the byte array. The receiver, once it has received all bytes (as given by the byte count) processes the data and then returns the response preceded by a byte count. Of course your application may be more complex than that, which is why protocol design is such an interesting problem. Original message From: James Richters via fpc-pascal Date: 11/09/2020 21:59 (GMT+00:00) To: 'FPC-Pascal users discussions' Cc: James Richters Subject: [fpc-pascal] Sending Hex codes over TCP/IP I'm trying to figure out how to send and receive Arrays of Bytes or perhaps a buffer of hex codes over TCP/IP, but everything I find seems to want to send and receive strings. Can someone please point me in the right direction on how to do this? Basically I want to make a connection to an IP address at a specific port and then send some bytes to the server then get some bytes back from the server. The data sent is just hexadecimal and it can't be followed by linefeeds or carriage returns, and I want to just receive the bytes back into a buffer of some sort so I can look at it one byte at a time. I prefer some kind of array of bytes so I can just access the bytes with elements of the array. I've been going round and round trying to figure this out. Any help is greatly appreciatedJames___fpc-pascal maillist - fpc-pascal@lists.freepascal.orghttps://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to check if a network is available?
Yep, that's the golden rule in networking. The only way that you know that a bi-directional path is open is an end-to-end ping. Even then, you only know that it's open at the time the ping completed. If you are using TCP then you can always enable keepalive packets that effectively do the same thing while the TCP connection is open. The IPsec Internet Key Exchange Protocol also has the same capability for Dead Peer Detection (DPD) which works between the two end points of a VPN tunnel. On 18/06/2021 13:34, James Richters via fpc-pascal wrote: Do a Ping to an address on the network to see if it's connected? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal I would like to know how I can check if a remote network is available, i.e. if the VPN system has succeeded to connect the remote network. I need this in a class that connects an OpenVPN tunnel on demand and takes it down after use. Unfortunately openvpn-gui does not have an API call to do this... It provides an API for connect, disconnect, reconnect etc but not for returning the state of a connection for example. https://github.com/OpenVPN/openvpn-gui#send-commands-to-a-running-instance-of-openvpn-gui Any suggestions for Windows? I just want to know if a call to connect succeeded. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Repost: TFieldType declaration change in FPC fixes_3_2 branch
Yes - but is that really a bug fix that justifies a non-backwards compatible change? On 17/10/2021 11:09, Michael Van Canneyt via fpc-pascal wrote: On Sun, 17 Oct 2021, Tony Whyman via fpc-pascal wrote: /Reposted with correct branch identifier/. I thought that a fixes branch was only for bug fixes and not for issuing non-backwards compatible changes. However, TFieldType in db.pas now has 6 extra elements. The result is that IBX no longer compiles with the fixes_3_2 branch. I have also heard the same for zeoslib. Is the rollout of this patch to fixes_3_2 a mistake, or is there a good reason for rolling out a change that breaks other packages? Delphi compatibility fix: fcl-db: base: add some of new Delphi field types into enumeration TFieldType (ftOraTimeStamp, ftOraInterval, ftLongWord, ftShortint, ftByte, ftExtended) Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Repost: TFieldType declaration change in FPC fixes_3_2 branch
/Reposted with correct branch identifier/. I thought that a fixes branch was only for bug fixes and not for issuing non-backwards compatible changes. However, TFieldType in db.pas now has 6 extra elements. The result is that IBX no longer compiles with the fixes_3_2 branch. I have also heard the same for zeoslib. Is the rollout of this patch to fixes_3_2 a mistake, or is there a good reason for rolling out a change that breaks other packages? Tony Whyman MWA Software ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Issue #39746 fpwidestring case conversion string too long
This issue seems to be still open after one year. There was a proposed fix: https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/158. However the discussion seems to tail off without an obvious resolution. This is a clear bug in fpwidestring and needs to be fixed. What is the status? A workaround using the Trim function seems to work (e.g. Trim(AnsiUpperCase(s))) - I am just not sure if it works all the time. Tony ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] I am offering a $100 reward for linking static libraries
Once upon a time (late-1990s) I had some reasonable success (shareware)
marketing a JPEG library for Delphi. This was a wrapper around the
Independent JPEG Group's JPEG software which was written in 'C'. My JPEG
library had thus to link to a 'C' library and both dynamic and static
linking was offered. I too had the problem of too many C DLLs to link in.
The way it was solved for static libraries was to first link in the JPEG
object files e.g.
{IDG JPEG objects modules to both compression and decompression}
{$L jdapimin.obj}
{$L jmemmgr.obj}
{$L jmemnobs.obj}
{$L jerror.obj}
{IDG JPEG modules for decompression}
{$L jdinput.obj}
{$L jdtrans.obj}
...
and then to identify the missing 'C' library functions (via linker
errors). I then wrote Pascal equivalents (placed just before the $L
statements. e.g.
{ Stubs for external C RTL functions referenced by JPEG OBJ files.}
function _malloc(size: Integer): Pointer; cdecl;
begin
GetMem(Result, size);
end;
procedure _free(P: Pointer); cdecl;
begin
FreeMem(P);
end;
procedure _memset(P: Pointer; B: Byte; count: Integer);cdecl;
begin
FillChar(P^, count, B);
end;
procedure _memcpy(dest, source: Pointer; count: Integer);cdecl;
begin
Move(source^, dest^, count);
end;
function __ftol: Integer;
var
f: double;
begin
asm
leaeax, f // BC++ passes floats on the FPU stack
fstp qword ptr [eax] // Delphi passes floats on the CPU stack
end;
Result := Trunc(f);
end;
As long as you can reduce the missing dependencies to a relatively small
number, it should all work.
Regards
Tony Whyman
MWA
On 21/08/2022 18:34, Anthony Walter via fpc-pascal wrote:
I will pay $100 to the first person that can solve my problem of
linking a compiled C static library to a Free Pascal program on Windows.
Recently I have been building many C libraries with GCC on Linux and
linking them to Free Pascal. These include building C libraries such
as "libxmp" for decoding mod/tracker music into PCM audio samples,
"libchuimpmunk2d" for simulating 2D solid body physics, or "libsdl2"
for cross platform controller input and haptic feedback among other
things.
So far on Linux I am happily able to use a cmake/make/gcc toolchain to
build these C libraries from source and easily statically link them to
my Free Pascal programs.
Here is an example and abbreviated Pascal unit that links to a static
build of Chimpmunk 2D:
unit Chimpmunk2D;
interface
type
cpSpace = Pointer;
function cpSpaceNew: cpSpace; cdecl; external;
procedure cpSpaceDestroy(space: cpSpace); cdecl; external;
implementation
{$ifdef linux}
{$linklib c}
{$linklib m}
{$linklib chipmunk-linux}
{$endif}
end.
Where libchipmunk-linux.a is my static library build on Linux from the
Chipmunk2D C source code and is in the same folder as the source code
as "Chimpmunk2D.pas". This works fine on Linux.
I am also able to use mingw32 gcc to compile this same C source into a
static library for Windows using these two commands while inside the
folder containing the Chipmunk2D sources:
x86_64-w64-mingw32-gcc-win32 -static -static-libgcc -std=gnu99
-ffast-math src/*.c -Iinclude -c
x86_64-w64-mingw32-ar rcs libchipmunk-win.a *.o
rm *.o
The problem then arises when I try to use {$linklib chipmunk-win}. No
matter how I try to arrange the static dependencies I cannot resolve
missing functions.
Many attempts were made compiling against other mingw32 static
libraries for Windows.
{$ifdef windows}
{$linklib mingw32}
{$linklib mingwex}
{$linklib kernel32}
{$linklib msvcrt}
{$linklib chipmunk-win}
{$endif}
I get many errors similar to these below:
Verbose: Compiling resource
C:\Development\Projects\physics\lib\x86_64-win64\Physics.obj
Verbose: Linking C:\Development\Pascal\Projects\physics\Physics.exe
Physics.lpr(30,1) Error: Undefined symbol: ___chkstk_ms
Physics.lpr(30,1) Error: Undefined symbol: __mingw_raise_matherr
Physics.lpr(30,1) Error: Undefined symbol: __imp_WideCharToMultiByte
Physics.lpr(30,1) Error: Undefined symbol: __imp_IsDBCSLeadByteEx
Physics.lpr(30,1) Error: Undefined symbol: __imp_MultiByteToWideChar
Physics.lpr(30,1) Verbose: There were 5 errors compiling module, stopping
Verbose: Compilation aborted
BUT
If I use mingw32-w64 on Linux to create a DLL instead, then m
problems on Windows go away.
x86_64-w64-mingw32-gcc-win32 -static -shared -static-libgcc -std=gnu99
-ffast-math src/*.c -Iinclude -o libchipmunk-win.dll
However, I am not satisfied with an ever growing list of DLLs (I am at
6 currently) that must be deployed on Windows to build / run any
project using my Pascal toolkit. I thought I could resolve this static
linking problem on Windows at a later date, thus eliminating all the
DLLs required to run projects using my toolkit on Windows, but every
time I return to try another attempt I cannot resolve the external
dependencies of something like "libchipmunk-win.a".
Therefore, if anyone has expertise in the
[fpc-pascal] Can FPC link a program with static (.a) libraries on Windows
I have a Pascal program, compiled with FPC 3.2.2 and which appears to happily link and run with a static library compiled with gcc and having a ".a" prefix on linux. The functions in the static library and declared as external functions using the "external name name>" directive. The "".a" library is copied to the same directory as the program unit before compiling and linking. However, compiling the same program on Windows always seems to result in the loader complaining that the corresponding .dll is not present, indicating that instead of linking with the static library, the program is attempting to "statically" load the correspoinding dll at initialisation time. I have tried to force it to link with the static library (e.g. using the -Xt command line switch) but no luck. Hence the question, does FPC 3.2.2 support linking with static libraries on windows? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] case statement
On 16/12/2023 19:07, Gerhard Scholz via fpc-pascal wrote:
ELSE/OTHERWISE
I assume that came historically; the first implementation of a PASCAL
compiler I have seen had no else or otherwise in the case startement.
Some ater dialects introduced ELSE, other dialect(s) used OTHERWISE,
FPC then allowed both.
The historical context has interested me as well.
Going back to the original "Pascal User Manual and Report" (Jensen and
Wirth 1978), there is no Else/Otherwise clause for a case statement. The
syntax is given as (in the original BNF):
::= case of
|;] end
::= : |
::= | [ , ]
Note that the semi-colon is used here in its traditional Algol role as a
statement separator and not the 'C' usage as a statement terminator.
Back in the early eighties, I worked at ICL and we made extensive use of
the Prospero Pascal compiler building embedded systems based on the Z80
microprocessor. I still have a 1988 edition of the language
specification, and this uses EBNF to define the case statement as:
case-statement = "CASE" case-index "OF"
case-list-element {";" case-list-element }
[ ";" OTHERWISE statement][";"] "END"
case-index = expression
case-list-element = case-range-list ":" statement
case-range-list = case-range {"," case-range }
case-range = case-constant [".." case-constant ]
case-constant = constant
What is interesting about the above is not just that it uses "otherwise"
but that it insists on a semi-colon before the "otherwise". This may not
have been strictly necessary but it does enforce the separation between
the case -list-elements and the "otherwise", making the "otherwise"
clause into another case-list-element. It also aids readability and it
may be why I have always added a semi-colon after the final
case-list-element. Note that the final optional ";" is probably needed
to allow those that always like to end a statement in a semi-colon.
Prospero Pascal was close to ISO Pascal (although I have lost my
original copy of ISO Pascal) and I would guess that the above is copied
from ISO Pascal.
The change from "otherwise" to "else" is probably a Borland Pascal
invention preferring a shorter word and then overlooking the importance
of the semi-colon case-list-element separator and the resulting
ambiguity. The same error then flowed through to exception handling.
As an aside, I much prefer OTHERWISE to ELSE given that it is much
closer to natural language. The IF...THEN..ELSE construct probably dates
back to Algol 60 and I wonder why it was proposed. In normal English
use, "else" is not used in this way. It usually follows another word,
such as "anyone else", "anything else", "or else".
You might say
"If I go to town then I will be out. Otherwise, I will stay at home". I
would never replace "otherwise" with "else" in such a sentence. "Else"
belongs in a statement such "Does anyone else have a view".
Tony Whyman
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] RIP: Software design pioneer and Pascal creator Niklaus Wirth
"Swiss computer scientist Professor Niklaus Wirth died on New Year's Day, roughly six weeks before what would have been his 90th birthday." https://www.theregister.com/2024/01/04/niklaus_wirth_obituary/?utm_source=daily_medium=newsletter_content=top-article ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] client certificate mandatory and verification
If you want to use OpenSSL then you might be interesting in trying out
my proposed update to the Indy components. This is to support the latest
versions of OpenSSL and can be downloaded from:
https://github.com/MWASoftware/Indy.proposedUpdate
There is a test case in Test/OpenSSL/openssl-server which is based on
the use of the Indy http server and OpenSSL which includes a test case
where a client certificate must be validated by the server. This appears
to work on both Linux and Windows and hopefully other platforms.
On 10/04/2024 01:34, Flávio Etrusco via fpc-pascal wrote:
Hello,
This doesn't seem to have an easy solution right now. Many of the
functions needed to set up openssl for this doesn't even seem to have
imports in the FPC package.
You'd then have to import the functions and implement a custom
TSSLSocketHandler, and then hook it using either
(fphttpapp.)Application.HTTPHandler.HTTPServer.OnGetSocketHandler or
TSSLSocketHandler.SetDefaultHandlerClass();
Some pointers:
https://stackoverflow.com/questions/4261369/openssl-verify-peer-client-certificate-in-c
https://stackoverflow.com/questions/21050366/testing-ssl-tls-client-authentication-with-openssl
https://stackoverflow.com/questions/16291809/programmatically-verify-certificate-chain-using-openssl-api
https://stackoverflow.com/questions/3412032/how-do-you-verify-a-public-key-was-issued-by-your-private-ca
Best regards,
Flávio
Em sáb., 23 de mar. de 2024 às 08:47, Jos Wegman via fpc-pascal
escreveu:
Hi,
Out of the info on the wiki I created a simple Webserver with a
server-certificate.
To get this code working you need to create the necessary certificate.
For this I used xca from https://hohnstaedt.de but you can use
OpenSSL to do the same.
[code=pascal]
program webserver;
{$mode objfpc}{$H+}
uses
{$ifdef UNIX}
cthreads, cmem,
{$endif}
fphttpapp,
httpdefs,
httproute,
opensslsockets;
var
fUseSSL: boolean;
const
fCertificatePassword: string = 'hello';
fCertificateHostName: string = 'localhost';
fCertificateFileName: string = 'Server.crt';
fCertificatePrivateKey: string = 'Server.key';
procedure route1(aReq: TRequest; aResp: TResponse);
begin
aResp.Content := 'Route 1 The
Default';
end;
procedure route2(aReq: TRequest; aResp: TResponse);
begin
aResp.Content := 'Route 2';
end;
begin
HTTPRouter.RegisterRoute('/', @route1);
HTTPRouter.RegisterRoute('/2', @route2);
Application.Port := 1999;
fUseSSL :=true;
Application.UseSSL := fUseSSL;
if fUseSSL then
begin
Application.CertificateData.KeyPassword := fCertificatePassword;
Application.CertificateData.HostName := fCertificateHostName;
Application.CertificateData.Certificate.FileName :=
fCertificateFileName;
Application.CertificateData.PrivateKey.FileName :=
fCertificatePrivateKey;
end;
Application.Threaded := True;
Application.Initialize;
Application.Run;
end.
[/code]
My questions are:
*- How can I modify this example to enforce the use of a client
certificate?
- How can I verify a client certificate in the server?*
In the TLS handshake a client certificate is optional but the
server can ensure that it is mandatory.
Any help, pointers, sample code is appreciated.
Sincerely,
Jos
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist -fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] FPC 3.3.x breaks the Firebird Project's Firebird.pas
This is a problem reported to me by an IBX user. I have not yet
confirmed it (need to find the time to set up the latest development
branch of FPC), but the issue looks solid, and is due to the following
addition to TObject (copied from the GitLab master branch)
|TObject = class|{$IFDEF SYSTEM_HAS_FEATURE_MONITOR}
strictprivate
_MonitorData : Pointer;
private
functionSetMonitorData(aData,aCheckOld : Pointer):Pointer; inline;
functionGetMonitorData:Pointer; inline;
{$ENDIF}
...
Since Firebird 3.0, the Firebird project has provided a file called
"Firebird.pas" in order to provide an interface to Pascal (both Delphi
and FPC) from a C++ environment. There is an underlying assumption in
the interface. That is TObject contains no fields.
The idea is simple enough. There is a single entry point to the Firebird
client library with the Pascal signature
function fb_get_master_interface : IMaster; cdecl;
This returns a pointer to a structure that may contain fields but is
primarily a list of pointers to cdecl functions. These functions can
perform various tasks. In the case of IMaster, they can also return
similar structures representing other "interfaces".
On the Pascal side, IMaster is defined as a class with no virtual
methods and a single field called "vTable" and this is set to the
pointer to the structure returned by fb_get_master_interface. The rest
of the class comprises methods used to call functions from the vTable.
This makes IMaster look like a normal class and hides the use of
function pointers. The code is generated by a program know as "cloop".
All Firebird interfaces declared in Firebird.pas follow the same approach.
Given the assumption that TObject defines no fields, it is possible to
coerce the pointer returned by fb_get_master_interface to appear as an
object "instance" of the IMaster class, and similarly for every other
Firebird interface class. This coercion ceases to be valid as soon as a
field, such as _MonitorData is added to TObject.
It is probably a valid argument to say that this is Firebird's problem
as the TObject definition is an internal data structure. However, this
ignores a serious real world problem. A fix or workaround is needed and
that has to be in Firebird.pas. It would be a logistic nightmare to try
and change the C++ Firebird client DLL/SO.
Also, does anyone know whether a similar problem will arise with Delphi,
or is thus just an FPC issue?
One of the following seems to be needed:
a) Rewriting Firebird.pas to set the vTable field explicitly rather than
implicitly through coercion - ideally without breaking any user code...
(note: no current need to free IMaster etc)
b) Taking a different approach to introducing _MonitorData e.g.
i) Putting in a class helper (is this possible?)
ii) Having a version of TObject (e.g. TUnmonitoredObject) which is the
current TObject and making TObject a descendent class introducing
_MonitorData. The Firebird classes can then descend from
TUnMonitoredObject, either explicitly or as a result of a new compiler
directive setting the default class ancestor.
iii) Anything else that works.
I am primarily looking for a solution that will work with IBX, but also
one that I can suggest to the Firebird Devs to make generally available.
Tony Whyman
MWA Software
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC 3.3.x breaks the Firebird Project's Firebird.pas
Michael,
I believe that the diplomatic answer to your response is that it is
"disappointing". This is a serious problem and needs to be discussed.
Interfaces between modules written in different programming languages or
even built with different compilers are never easy and depend on having
published and stable definitions for each data type and structure. This
is a common problem for anyone using Pascal given how so many code
libraries are written 'C' or C++. Change can imply breaking many user
programs and should not be done lightly and for purely internal reasons.
Both object and class type data structures are published in the Free
Pascal Documentation and I do not believe that it is unreasonable to
expect that the FPC developers will do their best to maintain stability
for these structures as they would for any other data type. You seem to
think that assuming that the object data structure is a stable and well
known data structure that can be relied upon to be the same in each
successive compiler version is "an invalid assumption". If that is the
case then can we rely upon the stability of any data type and hence of
any interface between FPC and other language environments?
In the case of monitor data, you have said that Delphi have implemented
this as a "hidden" field. I presume that you mean that this uses a
technique such as a negative offset to the object instance pointer. This
would certainly be a good way to add system information to an object
without destabilising the data structure for the user. Surely the right
way to go.
The Firebird OO API may be the only interface library that uses the
existing object layout in order to implement the interface. That would
surprise me and there may well be more interfaces that are broken by
FPC 3.3.x.
In the case of the Firebird OO API a complete redesign will be needed to
work around your change - requiring a separation of the data blocks
exchanged via the interface, and the classes supporting them. Even
though a code generator is used, there are still about a hundred classes
to consider with some used as callbacks. The Firebird.pas unit itself
comprises about 14,000 lines of code and comments. You are asking
voluntary programmers to devote hundreds, perhaps thousands of hours of
time, to build and test a new interface design purely for the benefit of
FPC, when the existing design works with both Delphi and FPC and has
done so since the early part of the last decade. Until someone puts in
this effort Pascal users of Firebird will be restricted to using the old
legacy interface (which has not been updated since Firebird 2.5 and
misses many important features), keeping with the old version of the
compiler, or just moving to Delphi.
And, before going down this path, perhaps you might like to give a heads
up of what other changes are in the pipeline that may knowing break
interfaces to other programming environments.
Tony Whyman
On 02/05/2024 13:55, Michael Van Canneyt via fpc-pascal wrote:
On Thu, 2 May 2024, Tony Whyman via fpc-pascal wrote:
This is a problem reported to me by an IBX user. I have not yet
confirmed it (need to find the time to set up the latest development
branch of FPC), but the issue looks solid, and is due to the
following addition to TObject (copied from the GitLab master branch)
|TObject = class|{$IFDEF SYSTEM_HAS_FEATURE_MONITOR}
strictprivate
_MonitorData : Pointer;
private
functionSetMonitorData(aData,aCheckOld : Pointer):Pointer; inline;
functionGetMonitorData:Pointer; inline;
{$ENDIF}
...
Since Firebird 3.0, the Firebird project has provided a file called
"Firebird.pas" in order to provide an interface to Pascal (both
Delphi and FPC) from a C++ environment. There is an underlying
assumption in the interface. That is TObject contains no fields.
This assumption is not valid in Delphi either. It also has this field,
but
it is 'hidden' at a not-fixed location.
The idea is simple enough. There is a single entry point to the
Firebird client library with the Pascal signature
function fb_get_master_interface : IMaster; cdecl;
This returns a pointer to a structure that may contain fields but is
primarily a list of pointers to cdecl functions. These functions can
perform various tasks. In the case of IMaster, they can also return
similar structures representing other "interfaces".
On the Pascal side, IMaster is defined as a class with no virtual
methods and a single field called "vTable" and this is set to the
pointer to the structure returned by fb_get_master_interface. The
rest of the class comprises methods used to call functions from the
vTable. This makes IMaster look like a normal class and hides the use
of function pointers. The code is generated by a program know as
"cloop". All Firebird interfaces declared in Firebird.pas follow the
same approach.
Given th
