Hello,
I've tried to compile the following code with --delphi option toggled on, but the compiler reported tester.pas:17: error: reference expected, value given
program tester; uses gpc;
procedure CatchSignal(aSig : Integer); begin case aSig of 2, 3, 15 : {SigInt, SigQuit, SigTerm} begin end; end; end;
var OldSigInt : TSignalHandler; r,dummy:boolean;
begin
r:=InstallSignalHandler(SigInt,CatchSignal,true,false,OldSigInt,dummy); end.
Then I checked the declaration of InstallSignalHandler and tried the same with aSig's type changed to CInteger. It compiled fine, except when the --delphi switch was on, because then CInteger seemed to be unknown ;-(
Do you have any suggestions how to fix this problem?
Any help appreciated. I used the freshly uploaded beta gpc version 20041218, based on gcc-3.3.3.
Best,
Adam Naumowicz
====================================================================== Department of Applied Logic fax. +48 (85) 745-7662 Institute of Computer Science tel. +48 (85) 745-7559 (office) University of Bialystok e-mail: adamn@mizar.org Sosnowa 64, 15-887 Bialystok, Poland http://math.uwb.edu.pl/~adamn/ ======================================================================
Adam Naumowicz wrote:
Hello,
I've tried to compile the following code with --delphi option toggled on, but the compiler reported tester.pas:17: error: reference expected, value given
program tester; uses gpc;
procedure CatchSignal(aSig : Integer); begin case aSig of 2, 3, 15 : {SigInt, SigQuit, SigTerm} begin end; end; end;
var OldSigInt : TSignalHandler; r,dummy:boolean;
begin
r:=InstallSignalHandler(SigInt,CatchSignal,true,false,OldSigInt,dummy); end.
Then I checked the declaration of InstallSignalHandler and tried the same with aSig's type changed to CInteger. It compiled fine, except when the --delphi switch was on, because then CInteger seemed to be unknown ;-(
Do you have any suggestions how to fix this problem?
Well, InstallSignalHandler is not Delphi compatible, so you can't expect to be able to use it in `--delphi' mode.
You can turn if off locally (`{$gnu-pascal}'), either for the call, or while declaring a new type equivalent to `CInteger'.
Frank
On Tue, 21 Dec 2004, Frank Heckenbach wrote:
Well, InstallSignalHandler is not Delphi compatible, so you can't expect to be able to use it in `--delphi' mode.
Well, I've always considered the Delphi compatibility in GPC to be on the syntactic level only, correct me if I'm wrong. But what you say means that actually these new CInteger-s are not Delphi-compatible, and for this I can't see the reason very clearly...
You can turn if off locally (`{$gnu-pascal}'), either for the call, or while declaring a new type equivalent to `CInteger'.
Thanks, that works fine.
Best,
Adam Naumowicz
====================================================================== Department of Applied Logic fax. +48 (85) 745-7662 Institute of Computer Science tel. +48 (85) 745-7559 (office) University of Bialystok e-mail: adamn@mizar.org Sosnowa 64, 15-887 Bialystok, Poland http://math.uwb.edu.pl/~adamn/ ======================================================================
Adam Naumowicz wrote:
On Tue, 21 Dec 2004, Frank Heckenbach wrote:
Well, InstallSignalHandler is not Delphi compatible, so you can't expect to be able to use it in `--delphi' mode.
Well, I've always considered the Delphi compatibility in GPC to be on the syntactic level only, correct me if I'm wrong.
No, the dialect options affect also semantics -- the presence of some built-in declarations and in some cases also their behaviour (e.g. `mod').
But what you say means that actually these new CInteger-s are not Delphi-compatible, and for this I can't see the reason very clearly...
Simply, this code isn't Delphi compatible because Delphi won't compile it (it doesn't have `CInteger' nor `InstallSignalHandler' AFAIK).
Generally, the dialect options should be used only to make sure (almost -- there are probably bugs in GPC's dialect definitions) that the code runs on a certain other compiler, or when you *require* a *conflicting* non-default behaviour (such as BP's `mod') -- non-conflicting dialect extensions are generally all supported in default mode.
(Since modes can be changed anywhere via compiler directives, this is no real problem for practical purposes, just a nuisance sometimes.)
Frank
In message 1103637306.23262.412600@goedel.fjf.gnu.de, Frank Heckenbach ih8mj@fjf.gnu.de writes
or when you *require* a *conflicting* non-default behaviour (such as BP's `mod')
As a matter of interest, how does BP's 'mod' differ from other implementations?
Martin Liddle wrote:
In message 1103637306.23262.412600@goedel.fjf.gnu.de, Frank Heckenbach ih8mj@fjf.gnu.de writes
or when you *require* a *conflicting* non-default behaviour (such as BP's `mod')
As a matter of interest, how does BP's 'mod' differ from other implementations?
The ISO Pascal standard requires that (a) the result of i mod j is non-negative and (b) j is positive. Unlike most other Pascal compilers, GNU Pascal follows that standard, except for the language dialects --borland-pascal and --mac-pascal.
Regards,
Adriaan van Os