10

In Delphi XE or 2006, is there any way to detect at compile time that implicit conversions between integer types may lose data? I realize it's possible to detect this with runtime checking. I would want it to flag the following example even if the "big" value were 1. (We're considering changing int to bigint for certain database keys and want to determine the impact on a large legacy codebase.)

program Project1;

{$APPTYPE CONSOLE}

uses
  SysUtils;

var
  small: Integer;
  big: Int64;
begin
  big := 3000000000000;
  small := big;  // Detect me!

  Writeln(small);
end.
TrueWill
  • 25,132
  • 10
  • 101
  • 150

2 Answers2

10

You won't get any warnings or hints at compile time. The Delphi compiler does not do any program flow analysis which tells it that big contains a too large value when it is assigned to small. It silently truncates the value to make it fit in the smaller type. I tried with Shortint, a signed byte-sized type and even that did not give a warning or hint.

And there is no way to make Delphi warn you. It would be nice. Perhaps you can suggest it in QC (if it wasn't already suggested)?

Rudy Velthuis
  • 28,387
  • 5
  • 46
  • 94
  • No need for new features since range checking catches all such defects – David Heffernan Jul 28 '11 at 23:12
  • 5
    It catches it at _runtime_. It would be nice to get a _compile time_ hint or warning about loss of precision or truncation of values. – Rudy Velthuis Jul 28 '11 at 23:20
  • compiler can't know until run time what a variable contains – David Heffernan Jul 29 '11 at 07:17
  • @David - agree, but for this type of a simple variable assignment might be more predictable and warn about it –  Jul 29 '11 at 08:00
  • 3
    @daemon would be a lot of effort to add such a feature for trivial return. Time better spent writing 64 bit compiler and fixing all the defects in the product. – David Heffernan Jul 29 '11 at 08:04
  • 1
    @David: the compiler can warn that you are assigning an 8 byte type like Int64 to a 1 byte type like Shortint and that this may result in a loss of precision or truncation. Note that the compiler does something similar for conversion between AnsiString and UnicodeString, even if the UnicodeString only contains code points in the ASCII range. – Rudy Velthuis Jul 29 '11 at 10:26
  • @David: in what way would it be a lot of effort? It just adds some diagnostics, and the compiler must already be aware of the conversion between different types and add code to truncate anyway. It just requires a little more verbosity. – Rudy Velthuis Jul 29 '11 at 10:31
  • OP is asking for warnings at compile time based on value of variables – David Heffernan Jul 29 '11 at 11:02
  • 1
    He is asking about implicit conversion between integer types, and that that may lose data. He wants warnings about this possible loss of data. He is not interested in values; he even says `I would want it to flag the following example even if the "big" value were 1.` So the value is not important. – Rudy Velthuis Jul 29 '11 at 11:07
  • 3
    @David - Rudy's correct. The value is not important; the implicit conversion is. Sorry about the ambiguity. – TrueWill Jul 29 '11 at 13:26
  • I'm of two minds about this: One one hand, I see the value of such a thing. On the other, the number of warnings that would be raised may very likely be *massive*. For those of us who like their compilations to be warning free, it'd generate a lot of noise and be a lot of work to track down and refactor or explicitly cast every warned expression. – afrazier Jul 29 '11 at 14:01
  • 1
    @afrazier: I'm not so sure there would be that many warnings. People do no tend to mix types that often. They tend to use the type that is declared for the variable that is assigned to it. -- And it could be someting that is switched on or off. – Rudy Velthuis Jul 29 '11 at 14:15
  • If the value doesn't matter then both question and answer need to be edited – David Heffernan Jul 29 '11 at 14:17
  • The very large value was merely to demonstrate that there is loss of information when you assign "big" to "small". The question is clearly about compile-time integer conversion warnings. – Rudy Velthuis Jul 29 '11 at 14:25
  • @rudy where does program flow analysis come into it then? – David Heffernan Jul 29 '11 at 15:49
  • Because the compiler could have seen (just as we do), that the value wouldn't fit. More or less as if the code had been: `small := 30000000000;`. The compiler doesn't do that either. – Rudy Velthuis Jul 29 '11 at 17:40
  • @rudy make your mind up. Is it about data type size, or the values in the variables at run time? One minute you argue one way, the next the other way. It's not a sign of weakness to improve your answers. – David Heffernan Jul 29 '11 at 18:00
  • @David - Rudy correctly answered my question to my satisfaction. I have edited the question to emphasize that this is about compile-time types, not run-time values. – TrueWill Jul 30 '11 at 16:23
  • @RudyVelthuis take a look into `Pascal Analyzer` – Zam Jan 11 '19 at 18:54
1

In Delphi, even in Delphi 10.3 -- no. But take a look into software calling 'Pascal Analyzer', mfg by www.peganza.com

They have a lot of options and one of them is (taken from software Help):

enter image description here

Source code for test, take a look into line #32:

enter image description here

Analyze result show possible bad assignment in line #32:

enter image description here

Zam
  • 2,880
  • 1
  • 18
  • 33