Ok, thanks. I am porting C code to Free Pascal. I want BP/TP compatibility (at least TP7). Original code has many functions in the following form obj * fun(obj * x) {
if (x == null} {
...
where obj is struct. Can I use my fu1 or not?
The test "if (x == NULL)" indicates that the function can accept a NULL/nil pointer, in that case, fu2 would be the better match to the C function because, fu2 allows a nil/NULL parameter as your C function currently does.
Again, as far as compatibility goes, that doesn't make any difference.
If I were you, I'd use fu2 because that way, the Pascal code will likely be completely parallel to the C code, that would not be the case if you used a declaration like fu1.
When I port C code to Pascal, except in the case of really simple programs, I normally do it in two passes. In the first pass, I make the Pascal code as parallel to the C code as possible (that's usually fairly straightforward), once that port is working correctly then, I look at the resulting Pascal code and determine what parts of it are better re-written using Pascal features.
ETA:where obj is struct. Can I use my fu1 or not?
The answer to that question is, yes you can, but, if you go that route, the Pascal code for C functions that accept nil as a parameter won't be "parallel". Here is an example of passing nil to a Pascal function declared to take a "var" parameter:
type
TStruct = record
i : integer;
end;
PStruct = ^TStruct;
function a(var p : TStruct) : boolean;
begin
writeln(IntToHex(ptruint(@p), 0));
result := true;
end;
begin
a(PStruct(nil)^);
To pass nil/NULL, you have to typecast nil and dereference it (personally, I find that to be very "unclean" - see line 15), then in the function you have to test not against "p" but "@p".
IMO, if a C function accepts nil/NULL as a parameter value, it is often not the best way to declare the parameter as a "var" because it unnecessarily complicates the code.
As far as compatibility, both are compatible with BP/TP but, using "var" results in an implementation that is likely more complicated than it should be.