9

We have a large Delphi XE codebase we want to port to 64 bit.

I own a Delphi XE2 licence and I cannot find any warning nor hint that can help me to detect valid 32 bit constructions that can now lead to data loss under a 64 bit platform. For instance, THandle to Cardinal assignments which were perfectly valid with the 32 bit compiler don’t raise any warning when compiling for Win64.

When migrating to Unicode with Delphi 2009, we had tons of warnings that helped us a lot to track and fix suspicious code. With XE2, I can’t find anything. I can’t imagine there is nothing integrated on the compiler level to avoid us to do a manual review of all our code.

Do I miss something ? How did you port you projects to 64 bit, if you tried ?

Thanks !

Adrien Reboisson
  • 631
  • 6
  • 15
  • `THandle` is not mapped to `integer` any more, but to `NativeUInt` (that is, a `cardinal` only under Win32). It may help identify the issues. – Arnaud Bouchez Nov 05 '11 at 10:52
  • I can't seem to get these kind of messages in XE (1) either, for instance assigning an int to a byte... – GolezTrol Nov 05 '11 at 11:01
  • 1
    @GolezTrol : you're right, but from my POV assignments that might lead to different results when they're compiled for Win32 or Win64 should introduce _a new class of compiler warnings_. – Adrien Reboisson Nov 05 '11 at 11:51

3 Answers3

2

You did not miss anything. There is nothing in the product to help you.

I too find this a little disappointing but I fully expect that the Emba designers thought about this. I can only conclude that their experience was that adding such warnings resulted in more noise than signal. The Delphi compiler has never warned when assigning to incompatible integer types. For example it has never been a warning or an error to assign an integer to a byte.

It's time to fire up grep and search for Integer\(.*\), Longint\(.*\), Cardinal\(.*\), Longword\(.*\), THandle etc.

To respond to Arnaud's comment and answer, I offer the following code which compiles free of warnings and errors when targetting 64 bit.

procedure NaughtyCode;
var
  Handle: THandle;
  int: Integer;
  card: Cardinal;
  P: Pointer;
begin
  Handle := high(Handle);
  int := Handle;
  card := Handle;
  P := Pointer(Handle);
  int := Integer(P);
  card := Cardinal(P);
end;
David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
  • I cannot understand why they did not include any OPTIONAL warning that would ease the process... Typecasts are one thing, but as I said, assignments from/to data types that have different sizes under Win64 (for instance, THandle) are far more difficult to grep and might lead to data loss/data corruption as well. I really don't understand their choice. – Adrien Reboisson Nov 04 '11 at 23:07
  • By using grep, searching is OK but everyone should be aware of not using it for a whole "replace" option - this may certainly break the code. In all cases, when compiled under Win64, `integer()` typecasts of `THandle` or `pointer` will raise an explicit compiler *error*. So IMHO searching is not mandatory: the compiler will make it on purpose for you, when setting the target platform to Win64. – Arnaud Bouchez Nov 05 '11 at 10:49
  • @Arnaud I must be doing something wrong. How do you configure XE2 to warn or error for the code I added to the question? – David Heffernan Nov 05 '11 at 11:04
  • I second you David. I don't get any error when compiling such code. – Adrien Reboisson Nov 05 '11 at 11:45
  • Explicit typecasts mean "I know what I'm doing here". You are asking for the compiler to stop assuming casts mean intentional actions. There are a few warnings for String to AnsiString IMPLICIT cast, but very few for EXPLICIT casting, because EXPLICIT casting is the fix. Now if explicit downcasts were even optional warnings, how do you write "clean code"? If Embarcadero listened to you, the whole compiler would get slower and bigger for something that really should be a separate tool, if anything. I would ask the author of Peganza PAL to add the features you want to PAL. – Warren P Nov 05 '11 at 12:38
  • 1
    Agreed for explicit typecasts. But what about what I would call "non-portable assignments accross platforms", where sizes of the involved types change depending on the target platform ? – Adrien Reboisson Nov 06 '11 at 00:27
0

About 5 years ago, I ported them to 64-bit Free Pascal. (even if only parts with a simple unit test to instrument them)

Testing with both compilers simply finds more issues.

Marco van de Voort
  • 25,628
  • 5
  • 56
  • 89
  • 1
    Thanks... Nevertheless, I would find a little bit depressing that you'd have to use TWO compilers to circumvent the limitations of the official one you bought at a significant price ! – Adrien Reboisson Nov 04 '11 at 20:30
  • @Adrien, what makes you think what Delphi is **official** Pascal compiler? – Premature Optimization Nov 04 '11 at 21:30
  • Well, AFAIK dcc64.exe is the "official" 64 bit Delphi compiler if you want to compile Delphi code. – Adrien Reboisson Nov 04 '11 at 21:43
  • For the life of me I can't see where Pascal comes into this. It's a question about XE2 64 bit Windows targets. – David Heffernan Nov 04 '11 at 21:58
  • Unfortunately, if the codebase does not compile under FPC, for example if it makes use of VCL, say, then FPC can't really help. – David Heffernan Nov 04 '11 at 22:03
  • @David Heffernan, complains about how expensive compiler purchase was are irrelated too, there is a trained customer service personnel for that. Anyway, `fpc` can build WIN64 targets for more than half of decade, this makes it a primary compiler to test compatibility issues. – Premature Optimization Nov 05 '11 at 00:22
  • @PrematureOptimization dcc is the official Delphi compiler. They haven't called it (Object) Pascal since Delphi 7, I think. – GolezTrol Nov 05 '11 at 10:59
  • @PrematureOptimization FPC could be helpful but vast majority of Delphi code is not actually compatible and will not compile at all due to the use of things like the VCL. So whilst this is a fine idea in principle, in practice it will frequently not be a viable option. – David Heffernan Nov 05 '11 at 11:14
  • 1
    David Heffernan: my app did. But I could easily compile large parts simply by creating a DPR and importing some units. For warnings that is enough. And the situation with Delphi<>FPC compatibility is not as bad you picture it. It sounds you tried it once with the bad expectation it would be a blind one time compile, and it pissed you off. It surely isn't a free ride, but that doesn't make it impossible or useless. Only if you use e.g. something Datasnap in every unit, then it is pretty hopeless. – Marco van de Voort Nov 05 '11 at 12:42
  • No that's not quite it. It's more a reflection of the fact that lots of code, mine included, was never intended for anything other than VCL. I would expect FPC not to compile it just as I would expect msvc not to. If your app is amenable to that then great. By the way, does FPC have the type of warnings that Dan is asking about? – David Heffernan Nov 05 '11 at 14:14
  • @David Heffernan, it should be stated as "vast majority of poorly written code" :-) As Marco said compilers are more compatible than you think. – Premature Optimization Nov 05 '11 at 14:32
  • @prem I'm very clearly talking about libraries rather than compilers – David Heffernan Nov 05 '11 at 14:37
  • @David Heffernan, standard libraries will compile. Think out of box. – Premature Optimization Nov 05 '11 at 14:38
  • David Heffernan: there is nothing left to discus. I can't help it if you want to see it as black as possible, comparing a Delphi compatible compiler that can compile heaps of known open source and commercial components to msvc that cannot even compile "begin writeln; end.", there is nothing to say anymore. It is too ridiculous to comment on. – Marco van de Voort Nov 05 '11 at 16:09
  • I think you are misunderstanding me. FPC is fantastic but it's not the same as Delphi. That's not criticism. It's fact. They are different. And yes it's clearly possible to adapt code to work with both compilers. But plenty of code only works with one compiler. All I'm saying is that my code is written for Delphi and I don't expect it to compile anywhere else. I have huge respect for FPC. Please don't take it personally. – David Heffernan Nov 05 '11 at 16:21
  • Now, what I would be fascinated to know, is specifically how the FPC compiler helped with 64 bit port. What kind of problems in your code did it detect? How configurable are the warnings? Whilst I could not readily deal with my entire app, what you describe could help with parts. – David Heffernan Nov 05 '11 at 16:25
  • To the first comment: probably neither can older delphi versions, and you don't go appending such comments every time sb mentions them. – Marco van de Voort Nov 05 '11 at 18:31
  • Nothing special. Mostly did everything people are doing for XE2 (killing unneeded assembler, fixing int<>pointer component.tag, header records alignment issues etc). Only difference it that I had a working internal assembler :-) As for general fault finding, the first bit is just different memory layout, because everything, while compatible, is a different implementation. If you have heisenbugs, chances are the behaviour is slightly different on FPC. Besides it has a randomize local variable option (to find uninitialized vars), and FPC binaries can be used with valgrind profiler/debugger. – Marco van de Voort Nov 05 '11 at 18:36
  • It also used to have a warning when there was los of precision when assigning ints (I remember finding many signed<>unsigned issues). I can't find it in the current iteration though. Maybe it is disabled because it was very spammy. There is a system to enable/disable all warnings and hints. – Marco van de Voort Nov 05 '11 at 18:37
  • Well I really didn't mean any criticism of FPC. I'm sorry I offended you. – David Heffernan Nov 05 '11 at 19:54
0

As you stated, most of the potential issues come from:

  • WinAPI changes (but most of the time identical/compatible);
  • THandle not mapped to integer any more, but to NativeUInt (that is, a cardinal only under Win32);
  • In pointer arithmetic, Integer typecast not mapped to NativeInt.

The latest will raise compiler errors, not only warning (it is an explicit type mismatch), and the THandle change should be warned as .

I won't be so hard with Embarcadero about the main compiler - I'm more concerned with the background compilers (e.g. CodeInsight) to be not synchronized with the main compiler. For me, the main compiler works fine, and I never complain about missing warnings. Just explicitly search for THandle is not so difficult.

Community
  • 1
  • 1
Arnaud Bouchez
  • 42,305
  • 3
  • 71
  • 159
  • Please see my updated question. So far as I can tell, what you state in this answer is factually incorrect. I'm not going to downvote because I respect the fact that you are invariably accurate and that it's more than likely that I have simply overlooked something. So please, what have I overlooked? – David Heffernan Nov 05 '11 at 11:05