2

This unit generates a warning that the value of frog might be undefined even though result is explicity set:

  unit homePage;

  interface

  function frog(const ts, fs: string; ci: integer; const ss: string; sb, sk, sr, ay, h: integer): string;

  implementation

  function frog(const ts, fs: string; ci: integer; const ss: string; sb, sk, sr, ay, h: integer): string;
  var
    s1, s2, s3, s4, s4a, s5, s6, s7, s8: string;
    m, i, j, n, sc, a, q, si, c, p, ct, f, pg, t: integer;
  begin
  m := 0; i := 0; j := 0; n := 0; sc := 0; a := 0; q := 0; si := 0; c := 0; p := 0; ct := 0; f := 0; pg := 0; t := 0;
  s1 := ''; s2 := ''; s3 := ''; s4 := ''; s4a := ''; s5 := ''; s6 := ''; s7 := ''; s8 := '';
  result := 'x';
  end;

  end.

The compiler (Delphi 6 build 6.240 with update pack 2) rightly warns the values assigned to the integers are never used. The original code (with much more descriptive variable names) actually sets or computes all the variables, so the only warning generated by the original code is about the function's return value; the above code has been minimized and still generates the mysterious warning. Unlike the integers, the compiler does not warn about the string variables never being used.

Just about any change to the above code (deleting or using any of the variables) makes the return value warning go away. No such luck with the original code, which always and only generates the warning the return value might be undefined.

Is this a bug in the compiler?

Dalija Prasnikar
  • 27,212
  • 44
  • 82
  • 159
  • FWIW: In Delphi XE6 I get a bunch of H2077 ("assigned value not used") but nothing else. Does the unit as you posted it here produce the "undefined" error? – Uli Gerhardt Apr 26 '23 at 06:21
  • Yes, the code above produces the error. Note that it's very old Delphi 6, not XE6. – Witness Protection ID 44583292 Apr 26 '23 at 06:26
  • "This unit generates a warning that the value of frog might be undefined even though result is explicitly set" It doesn't in Delphi 7, so I doubt it does in Delphi 6. Most likely: you are leaving something out – Dave Nottage Apr 26 '23 at 06:54
  • 1
    "The original code (with much more descriptive variable names) actually sets or computes all the variables". This is a big clue: the original code probably has the warning, but not this. Provide what causes the problem; not some modification of it – Dave Nottage Apr 26 '23 at 06:56
  • It is hard to tell whether there is a bug in the compiler or not since you haven't posed your actual code. However, in the code you posted compiler obviously chokes on warning it emits from unused variables so it fails to realize function result is assigned. If the all code paths actually assign the result, you might be able to clear the warning by assigning empty string to the function at the beginning of the function if there are no other warnings in your code. – Dalija Prasnikar Apr 26 '23 at 08:38
  • This is pretty old Delphi version so it is not unlikely that compiler detection of function result assignment is a bit flakey. Even in new Delphi versions there are situations where compiler cannot figure it out properly as it is not doing full static analysis of the code because that would take too long. – Dalija Prasnikar Apr 26 '23 at 08:40
  • Simple answer: If the compiler shows this warning about result not being assigned in the code you posted, it's a compiler bug. I get warnings like this in various Delphi versions while in others there is no warning. Most of the time, newer compilers are correct, but not always. I usually check whether the warning is real and if not, I turn it off for that function and that Delphi version. Since Delphi 6 is over two decades old, creating a bug report is pointless. So you will have to live with it, or you might consider updating to something more recent. – dummzeuch Apr 26 '23 at 09:06
  • 2
    For all the doubters above, the code posted is a perfect [mcve], it produces the described warning – David Heffernan Apr 26 '23 at 10:46
  • @DavidHeffernan Yes, the code above reproduces the warning, but only if you leave all other warnings untouched. Since OP said that his original code only has one warning about not assigned function result, then code presented here is not exactly minimal reproducible example. In other words solution for above code is removing unused variables or if you use them in some way. But I guess that kind of answer is not very helpful for resolving the issue. – Dalija Prasnikar Apr 26 '23 at 12:27
  • @DalijaPrasnikar Maybe the entire question is based on a false premise. But it's absolutely true that the compiler is wrong to say that the return value may not be assigned. – David Heffernan Apr 26 '23 at 13:03
  • @DavidHeffernan Yes, there is no doubt about the compiler emitting bogus warning in the presented code, unless you check with some newer version where this issue is not reproducible. – Dalija Prasnikar Apr 26 '23 at 13:21
  • 1
    @DalijaPrasnikar I mean the question is clearly for Delphi 6, which I happen to have on hand – David Heffernan Apr 26 '23 at 14:03

2 Answers2

2

Is this a bug in the compiler?

Yes. There's really nothing much more to say here. It seems like all those extra local variables confuse the compiler sufficiently for it to spit out this bogus warning.

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
  • 1
    Old compiler versions up to 6, maybe 7, were notorious for reporting warnings that were wrong. Including warnings about undefined return values. That was fixed in later versions. – Remy Lebeau Apr 26 '23 at 14:55
0

Most common cause for Delphi compiler warning W1035 Return value of function might be undefined is the fact that function result is being only assigned within one of conditional statements like:

Result assigned only within if statement

function MyFunction(AInput: Integer): String;
begin
  if AInput = 5 then
  begin
    Result := 'Some output';
  end;
end;

Result being assigned only within case statement

function MyFunction(AInput: Integer): String;
begin
  case AInput of
    1: Result := 'Some output';
    2: Result := 'Some other output';
  end;
end;

Also since loops are in a way conditional statements where you are repeating same code block multiple times until certain condition is being met you get the same W1035 compiler warning.

Result is being assigned only within for loop

function MyFunction(AInput: Integer): String;
var I: Integer;
begin
  for I = 0 to 10 do
  begin
    Result := 'Some output';
  end;
end;

Result is being assigned only in repeat loop

function MyFunction(AInput: Integer): String;
var I: Integer;
begin
  repeat
    Inc(I,1);
    Result := 'Some output';
  until I = 10;
end;

Result is being assigned only in while loop

function MyFunction(AInput: Integer): String;
var I: Integer;
begin
  while I < 10 do
  begin
    Result := 'Some output';
    Inc(I,1);
  end;
end;

All of these examples will raise W1035 compiler warning. Why? Because there is no guarantee that conditional statements required condition is met to execute that specific part of the code.

PS: If my memory serves me correctly Delphi 6 might also sometimes generate W1035 warning if result was being assigned only within try statement.

So I recommend you check your original code to see if result is being assigned only from within some conditional statements and add some default result assignment on the start of the very function.

SilverWarior
  • 7,372
  • 2
  • 16
  • 22