I've got a few thousand lines of Pascal which I'm converting to FPC. It's actually the Meta-2 compiler-compiler which despite its age I still find useful for embedded script processing, I hope eventually to get it running on SPARC and possibly ARM as well as x86. Linux will not be the first OS this code has run on, by any means.

This code was originally written using MT+86, but compatibility with that has been sacrificed and it now works with TopSpeed Pascal, TP5.5 and Delphi. Because it is still compilable with TopSpeed which doesn't use the "standard" directive and conditional-compilation format I'm having to be very careful with the source.

In one place I am checking a number of procedure variables which are actually callbacks for reading input etc., if they're NIL then default procedures are used instead. For portability I have defined myself a function

FUNCTION AddressOf(VAR x): POINTER;

Hence

IF AddressOf(source)  NIL THEN
   state.source:= source
ELSE
   state.source:= dummyRead;

That works OK with the other compilers but when compiling with FPC it reports "Wrong number of parameters specified for call to "<Procedure Variable>".

If instead I use

IF @source  NIL THEN
   state.source:= source
ELSE
   state.source:= dummyRead;

that works with FPC and probably other Borland-style compilers, but not with TopSpeed.

Is there a directive or mode that will allow a procedure variable to be compatible with AddressOf() as defined? Alternatively is there a type which is compatible with any procedure variable (i.e. like Modula-2's PROC, if my memory is correct), and can I overload AddressOf() to handle the specific case of a procedure passed as parameter while leaving it tolerant of other types?

FPC treats procedural types "a little" different from Delphi / TP, see
http://www.freepascal.org/docs-html/ref/refse17.html this . You can
therefore write your AddressOf function as:
FUNCTION AddressOf(VAR x): POINTER;
... // variables (if you ever need)
begin
{$ifdef fpc}
;
{$else}
... // for other compilers
{$endif}
end;

That's exactly what I'm doing at the moment- plus a whole lot of extra complexity due to having to accommodate two different directive formats.

The problem isn't defining the AddressOf() function, it's applying it to a procedure variable as shown in my original message.

No you cannot.

Did you try using Delphi mode ? The compiler uses other rules then.

Michael.

Shucks :-)

Did you try using Delphi mode ? The compiler uses other rules then.

Already am using (*$MODE DELPHI *)

After sleeping on the problem I've set up AddressOf as a macro with the value @ which certainly compiles- I'm not at the stage of running the program's own integrity tests yet.

From
http://lazarus-ccr.sourceforge.net/fpcdoc/prog/progse5.html#x121-1210002.2 I'm still a little uncertain whether macro definition uses := or = What I have found though is that using (* *) doesn't work- the definition has to be in {} However on the machine in question I'm still on version 2.2.0 of the compiler for various reasons.

Hello Mark,

Saturday, December 20, 2008, 1:40:15 PM, you wrote:

MML> Already am using (*$MODE DELPHI *)

Hmmm... this should be {$MODE DELPHI} do not ? using (* *) you get a comment, or maybe I'm wrong ?

In Delphi mode you must not need the @ for procedural assigns.

AFAIK (* *) comments are never directives in FPC.

Mattias

I am very sorry but I'm afraid that is not the case.

-----8<-----
0 2> cat test.pas
PROGRAM Test;

(*$NOTES ON *)
(*$NOTE This is a note. *)
BEGIN
   Write('Hello, ');
   WriteLn('World!')
END.

0 2> fpc test.pas
Free Pascal Compiler version 2.2.0 [2008/11/06] for sparc Copyright (c) 1993-2007 by Florian Klaempfl
Target OS: Linux for SPARC
Compiling test.pas
test.pas(4,3) Note: User defined: This is a note.
Assembling test
Linking test
9 lines compiled, 0.7 sec
1 note(s) issued
----->8-----

Apologies for my rather archaic programming style but I'm a refugee from Modula-2 and at one time I had this half-baked idea of writing code that could be easily machine-processed for both. Old habits die hard.

You are right.

Apologies for my rather archaic programming style but I'm a refugee from Modula-2 and at one time I had this half-baked idea of writing code that could be easily machine-processed for both. Old habits die hard.

Mattias