What are your compiler settings for debug builds?

[David Heffernan 2345]

8 minutes ago, Vandrovnik said:

Of course I cannot guarentee it. But you wrote "Giving the user the wrong results is always worse than showing an error, even if the error is poorly worded.", so I gave you an example, where error message would be worse than ignoring the error.

Yes, but since you don't know that the error will be inconsequential, it's kinda pointless looking at the impact. 

[Mike Torrettinni 198]

In perfect world, there would be no 'idiot' developers who can't handle exceptions correctly. But we all have used software where approximation, 'as best as possible' or 'good enough' is used. Just think of any diff tools (do they always show 100% correct difference or line alignment?), any drawing tools (have you ever checked if pixels are 100% correct if doing something a little more than basic stuff) and so on... error messages in such cases would be absurd. Of course, as mentioned, some software like accounting should be 100% correct.

 

I guess my customers prefer reporting incorrect results vs error messages, so Range checking is off in release version.

[Sherlock 663]

I get it, I really do, but how do your customers catch incorrect results? And how do they know they are not getting incorrect results all of the time?

[Mike Torrettinni 198]

1 minute ago, Sherlock said:

I get it, I really do, but how do your customers catch incorrect results? And how do they know they are not getting incorrect results all of the time?

Well, imagine you have analytical feature that analysis 1000s of data connection points. And the results just give you the sense of connections between data, so if it shows 499 instead of 500 connections is not such a big deal. If it shows only 1 instead of 2, could be huge issue since it's missing 50% of the results, or you are actually expecting the 2 and you report that 1 is missing. And let's say you are browsing though 10s of data objects with the connections to get the broad view of the connections. In this case it would be extremely annoying if the first example (499 out of 500) would block the whole usability. of the tool until bug is fixed.

So, screenshots and detailed description is usually enough to track down and fix the issue.

[David Heffernan 2345]

People for sure would rather have an error message than incorrect results. You are just kidding yourself if you say otherwise. It's simple human denial. 

 

Suppressing errors will result in a program with more defects. We all know this to be true. And yet people still choose the path with more defects. 

 

What happens when you access an array out of bounds with range checking disabled? Perhaps the memory is valid and so the program continues running. But now it's behaviour is unpredictable. Often you will corrupt memory which leads to obscure errors later that you can't tie back to the original defect. Or quite often it's a straight AV which is hardly preferable to a range check error, since it isn't reproducible.

[Mike Torrettinni 198]

1 minute ago, David Heffernan said:

It's simple human denial

By now you should know I'm in some sort of denial (especially when it comes how much dev books I should read) 😉 

I didn't want to hijack this thread, but as always I will get something out these debates, even though I got a little triggered by some comments.

 

I'm just releasing new software and I will rethink the whole Range on/off in release version. Thanks!

[Fr0sT.Brutal 900]

17 hours ago, Sherlock said:

Apple for example highly discourages to display error messages in their iOS human interface guidelines. BUT they do encourage logging, and offer means to retrieve those logs from devices.

I hate this in Android. Just an "Application has been closed" message or even worse, it just silently shuts down and you sit there like a cave man trying to handle a magic box, calling for gods' mercy to make the spirit of that magic box obey.

 

Anyway there are different errors. Some of them shouldn't be ignored (memory corruption), some should be handled carefully (critical crash in processing but save user's data before shutdown) and some could be ignored.

I always use range/overflow checking because little slowdown is better than buffer overrun vulnerability that could lead to malicious code execution,  data leakage or app's hard crash - all these things we love in C/C++ apps *sarcasm*

[Sherlock 663]

@Mike Torrettinni I hope you did not feel triggered by me. I am really interested in your use case. I have users, that simply don't care about IT, they are forced into using my software (healthcare professionals especially midwifes sometimes seem to have chosen their job, because they hoped to never use a computer). So I have to keep the error messages to a minimum, in very rare cases resulting in a painful process of almost restarting the complete application - unbeknownst to the user. Just so they don't find a reason to stop using the software, and believe me, they are looking for one all the time

[Stefan Glienke 2002]

Range checking is an interesting thing - lets look at the compiler output for the following code with range checking:

procedure Test;
var
  numbers: array of Integer;
  i: Integer;
begin
  SetLength(numbers, 10000000);

  for i := Low(numbers) to High(numbers) do
    numbers[i] := i;
end;

Project376.dpr.18: for i := Low(numbers) to High(numbers) do
004CF162 8B45FC           mov eax,[ebp-$04]
004CF165 85C0             test eax,eax
004CF167 7405             jz $004cf16e
004CF169 83E804           sub eax,$04
004CF16C 8B00             mov eax,[eax]
004CF16E 8BD0             mov edx,eax
004CF170 4A               dec edx
004CF171 85D2             test edx,edx
004CF173 7C1B             jl $004cf190
004CF175 42               inc edx
004CF176 33C0             xor eax,eax
Project376.dpr.19: numbers[i] := i;
004CF178 8B4DFC           mov ecx,[ebp-$04]
004CF17B 85C9             test ecx,ecx
004CF17D 7405             jz $004cf184
004CF17F 3B41FC           cmp eax,[ecx-$04]
004CF182 7205             jb $004cf189
004CF184 E86F96F3FF       call @BoundErr
004CF189 890481           mov [ecx+eax*4],eax
004CF18C 40               inc eax
Project376.dpr.18: for i := Low(numbers) to High(numbers) do
004CF18D 4A               dec edx
004CF18E 75E8             jnz $004cf178

Now without range checking:

Project376.dpr.18: for i := Low(numbers) to High(numbers) do
004CF162 8B45FC           mov eax,[ebp-$04]
004CF165 85C0             test eax,eax
004CF167 7405             jz $004cf16e
004CF169 83E804           sub eax,$04
004CF16C 8B00             mov eax,[eax]
004CF16E 8BD0             mov edx,eax
004CF170 4A               dec edx
004CF171 85D2             test edx,edx
004CF173 7C0D             jl $004cf182
004CF175 42               inc edx
004CF176 33C0             xor eax,eax
Project376.dpr.19: numbers[i] := i;
004CF178 8B4DFC           mov ecx,[ebp-$04]
004CF17B 890481           mov [ecx+eax*4],eax
004CF17E 40               inc eax
Project376.dpr.18: for i := Low(numbers) to High(numbers) do
004CF17F 4A               dec edx
004CF180 75F6             jnz $004cf178

The question is: does this code even need range checking? The answer is no - the loop range itself guarantees it.

 

What if the compiler would notice if I mistakenly would write:

for i := Low(numbers) to Length(numbers) do
  numbers[i] := i;

instead of putting some code that slows things down and can optionally be turned off.

 

Of course this is a simple example of an out of range error and there are others that are not easily noticeable at compiletime - but those that are the compiler (or static code analysis) could do a whole lot of potential error detection.

[dummzeuch 1505]

1 hour ago, Stefan Glienke said:

Range checking is an interesting thing - lets look at the compiler output for the following code with range checking:

procedure Test;
var
  numbers: array of Integer;
  i: Integer;
begin
  SetLength(numbers, 10000000);

  for i := Low(numbers) to High(numbers) do
    numbers[i] := i;
end;

The question is: does this code even need range checking? The answer is no - the loop range itself guarantees it.

Unfortunately it's not always that simple:

 

Assume a sub-procedure (since numbers is not a field):

procedure GetItem(_idx: integer): integer;
begin
  Result := numbers[_Idx];
end;

Then call it with an invalid index. Range checking would detect it.

Of course you could add code that checks for it:
 

if (_Idx < Low(Numbers)) or (_Idx > High(Numbers) then
  raise EProgramerTooBloedError.Create('The programmer is an idiot!');

but then we are back to having to write code that could be autogenerated.

Edited February 5, 2020 by dummzeuch

[Uwe Raabe 2057]

There is always the option to turn range checking off for a dedicated code part. 

[Stefan Glienke 2002]

1 hour ago, Uwe Raabe said:

There is always the option to turn range checking off for a dedicated code part. 

Unfortunately there is not - iterating any RTL list in a proper way (for i := 0 to list.count-1) will execute range checking code (not the compiler inserted but explicitly coded) and even for x in list code does (check System.Classes.TStringsEnumerator.GetCurrent as example)

[Uwe Raabe 2057]

22 minutes ago, Stefan Glienke said:

(not the compiler inserted but explicitly coded)

If it is explicitly coded there is of course no option to turn it off (except changing the code), but the ability to turn it off is the foundation of this poll.

[Stefan Glienke 2002]

Just saying... RSP-16751

[David Heffernan 2345]

This is one of the reasons why the cool cats don't use RTL collections

Edited February 5, 2020 by David Heffernan

[Renate Schaaf 64]

What is the reason for turning optimization off? Are there any pitfalls when having it on?

Edit:

I remember now, there are problems with the debugger not showing stuff that's optimized out, is that all?

Edited February 18, 2021 by Renate Schaaf