Hi All,

I use MWA's IBX for Firebird connection and have problem with date parameters. Tony provided to me a test program a suggested write to the FPC list. The simple test program is:

program Project1;
uses Variants, Sysutils;
var V: variant;
     D: TDate;
begin
   D := EncodeDate(2016,10,20);
   V := D;
   writeln('date is ',VarType(D));
end.

The result is: "date is 5" (varDouble)

If modify D: TDate; to D: TDateTime; the result is "date is 7" (varDate)

I (We) missed something or is this a bug?

Gabor

Only TDateTime is automatically converted correctly to Variant. TDate and TTime are distinct types and not automatically converted. They are seen as doubles (the original type of TDateTime).

If Delphi prints another result, then we can look at fixing the implementation.

Michael.

Dňa 2.11.2016 o 11:38 Michael Van Canneyt napísal(a):

Delphi7 prints 5
Of course you can use V := TDateTime(D); then prints 7

-Laco.

2016. 11. 02. 11:38 keltezéssel, Michael Van Canneyt írta:

If Delphi prints another result, then we can look at fixing the implementation.

With Delphi 10.1 and "D: TDate;" the result is "date is 5" and with "D: TDateTime;" the result is "date is 7". So, the results are same with FPC and Delphi.

Gabor

It's an interesting concept i.e. if a bug exists in Delphi then it must also exist in FPC. Perhaps a better alternative is to fix these sort of bugs in FPC and to introduce a "full Dephi compatibility mode" i.e. mode Delphi plus the bugs.

Tony Whyman wrote

It's an interesting concept i.e. if a bug exists in Delphi then it must also exist in FPC.

Yes I agree. FPC's Interfaces support suffer the same fate. eg: FPC's CORBA style interfaces which Delphi doesn't have, implements the same bugs as Delphi COM Interfaces???

I would prefer FPC to be bug free, no matter the compiler mode. If you want bugs (and don't mind paying for them), stay with Delphi. If you want a better compiler which is bug free, move to Free Pascal.

Regards,
Graeme

Probably handling TDate as TDateTime in FPC is adding:

operator :=(const source : TDate) dest : variant;{$ifdef
SYSTEMINLINE}inline;{$endif}
   begin
     VariantManager.VarFromTDateTime(Dest, TDateTime(Source));
   end;

in case of Delphi (at least 7) TDate is defined in Controls, so Variants cann't depend on Controls.TDate ...

-Laco.

Tony Whyman wrote

It's an interesting concept i.e. if a bug exists in Delphi then it must also exist in FPC. Perhaps a better alternative is to fix these sort of bugs in FPC and to introduce a "full Dephi compatibility mode" i.e. mode Delphi plus the bugs.

There is a difference between having a code construct that can be compiled in one mode and not in another, and code that has different behaviour in different modes. The former can be easily recognised, the latter is much harder. In particular, it complicates reading code, because you constantly have to be aware of the mode to know what the code means. The same goes for changing behaviour across compiler versions, and we have to do this way more often than I like.

Both of those things are symptoms of the worst possible situation you can have in terms of code readability, while it is supposed to be one of the focus points of Pascal.

We already have a few cases of code that compiles both in FPC and in Delphi mode, such as this:

function func: longint;
begin
   func:=1;
   if func2 then
     writeln('ok');
end;

In FPC mode this writes 'ok'. In Delphi mode this causes endless recursion. These are the worst kinds of gotchas, and most of them were introduced in the early days of FPC when we indeed thought we would fix everything that is wrong with TP. In the end, in many cases we just introduced our own set of idiosyncrasies that you have to know about to avoid getting bitten.

As Lacak mentioned, you can change the behaviour of this particular case yourself if you want, without having to go over all existing code written in FPC/ObjFPC mode to ensure that none of it relies on the existing behaviour (assuming that this would be changed by adding the extra operator Laco mentioned in a unit that would only be included in programs compiled in FPC/ObjFPC mode).

Jonas

There was a certain amount of sarcasm in my comment that perhaps got lost in translation. I suggested introducing a "delphi with bugs" mode to illustrate the absurdity of the idea. My point is that why should FPC still feel constrained by Delphi? Let's get on and fix the bugs/features that Delphi should have fixed long ago.

Please read my reply again. I was not talking about the downsides of a hypothetical "delphi with bugs" mode. I was talking about the downsides of changing the FPC/ObjFPC modes. I explained what the downsides would be of doing so, even if the collective "us" would have the ability to know in advance all of these changes' unintended consequences.

Jonas