3

Given the following code where the return value is not set, what is returned?

Function MyFunction : Integer;  
begin  
end;
John Livermore
  • 30,235
  • 44
  • 126
  • 216

1 Answers1

8

The returned value is undefined; it can be anything.

Hence, this is a bug.1, 2

In fact, the compiler warns you about it:

[dcc32 Warning]: W1035 Return value of function 'MyFunction' might be undefined.

1 I thought this was obvious, but clearly not: I mean that it is a bug when a function doesn't set the Result variable. So, if a Delphi programmer writes a function that, under some conditions, fails to assign a value to Result, then that programmer has made a mistake and should fix it ASAP. I did not mean that there is a bug in the Delphi language or the Delphi compiler.

2 Well, it doesn't have to be a bug, but almost always it is - at least in sane code. The exception would be if the contract of the function explicitly says that the returned value is undefined under some specific and testable condition. For instance, we all know about the TryXToY idiom, like TryStrToInt(const S: string; out Val: Integer): Boolean. If the conversion is possible, the function returns True and Val is assigned. If not, the function returns False and Val might well be left undefined. You could, in theory, write a function with the opposite behaviour, where the "definedness" of the result is given by an out parameter. That, however, would be very counter-intuitive to most programmers, so it would be a bad idea.

Andreas Rejbrand
  • 105,602
  • 8
  • 282
  • 384
  • This is also documented: http://docwiki.embarcadero.com/RADStudio/Rio/en/Procedures_and_Functions_(Delphi)#Function_Declarations – Andreas Rejbrand Dec 19 '19 at 21:17
  • 1
    I think it is worth noting that there may not be a warning if the function's result type is implemented as a var parameter. https://stackoverflow.com/questions/3250827/initialise-string-function-result/3251381 – Ken Bourassa Dec 19 '19 at 21:29
  • @Ken: Good point. Arguably, this is a flaw in the compiler, since an undefined string result is just as bad as an undefined integer result (for instance). – Andreas Rejbrand Dec 19 '19 at 21:35
  • Probably also worth noting that the value depends on what data just happens to be sitting at the memory address allocated to the function result. – Jerry Dodge Dec 20 '19 at 02:47
  • @AndreasRejbrand it's even worse with interfaces. – dummzeuch Dec 20 '19 at 08:22
  • 1
    @AndreasRejbrand This is not a bug but the way how code optimizer works. You see Delphi does not automatically set any default value to Result or local variables in order to avoid unnecessary calls that would set default initial state just to be changed a bit later by your own code. In both cases it is expected that your code will be setting some data to the Result or local variables before using them so setting default initial state is unnecessary. ... – SilverWarior Dec 21 '19 at 13:19
  • 1
    ... Not sure for newer Delphi versions but in older versions you could use compiler directive {$Optimization Off} to prevent Delphi compiler from optimizing part of your code. So using this directive on such function would force setting default initial state to the Result which in case of Integer would be 0. – SilverWarior Dec 21 '19 at 13:21
  • Afaik Delphi doesn't initialize non managed variables with optimization off? – Marco van de Voort Dec 22 '19 at 21:59
  • @SilverWarior: When I wrote "this is a bug", I meant it is a bug when a Delphi developer writes a function that doesn't (always) set the `Result`variable. I very much did *not* mean to imply that this is a bug in the Delphi language or compiler. Also, I am not sure at all that this is related to optimizations. But even if that is the case, I still think it is a bug (or, at the very least, very bad practice) to write a function that sometimes doesn't set `Result`. I mean, then you have a piece of code that suddenly starts displaying erratic behaviour when you turn on optimizations (normal)! – Andreas Rejbrand Dec 22 '19 at 22:08
  • @AndreasRejbrand I still don't agree with you. The shown function is not a bug but a terrible piece of code that WILL lead to bugs in other parts of the code where result from this function is used. And the reason why it will cause bugs in other parts of the code is because this function is introducing an unpredictable behavior since its result isn't initialized to some predictable default state but instead its state is dependent on the data that was previously stored in the memory block that was assigned to be used by the result at this time. – SilverWarior Dec 24 '19 at 15:23
  • @SilverWarior: I fail to see your point. Unless it is hugely important, I think we'll leave it here. Your initial comment very much suggested you interpreted my A as saying that the Delphi language/compiler has a bug. – Andreas Rejbrand Dec 24 '19 at 15:49