Range Checking

[graemejc]

This is not so much a help-me-please-question, rather it's a do-you-think-it-strange-too-question?

I recently wrote code which gave me a strange result and I realised that the reason was that I had copied code to manipulate a 9 element array for a different purpose and I only needed a 6 element array.

In trying to print out the 6 element array, I was accidentally trying to print 9 elements, and as no error was generated, it must be that no range checking was done. So searched the documentation and discovered that {$R+} or {$RangeChecks ON} will generate range checking code.

And that {$R-} or {$RangeChecks OFF} will disable generation of range checking code.

So, do-you-think-it-strange-too that the default is range checking OFF?

Or am I just showing my age and that my last regular programming experience was late 80s early 90s when range checking was an important part of Pascal.

[lucamar]

The default modes, both for Lazarus and FP/FPC, are a compromise between what could be termed "heavy debugging" and "full release" modes, so it adds a little debugging info but doesn't sets on the full-checking "artillery".

And if you're showing your age, I guess most of us do: I was also a little startled when I discovered it.

Do note, though, that the default configuration for Turbo Pascal also had range checking turned off:

Code: [Select]

Borland Pascal  Version 7.0  Copyright (c) 1983,92 Borland International
[... compiler options ...]
Compiler switches: -$<letter><state>  (defaults are shown below)
  A+ Word alignment       K+ Smart callbacks      S+ Stack checking
  B- Full boolean eval    L+ Local debug symbols  T- Typed pointers
  D+ Debug information    N- 80x87 instructions   V+ Strict var-strings
  E+ 80x87 emulation      O- Overlays allowed     W+ Windows stack frames
  F- Force FAR calls      P- Open string params   X+ Extended syntax
  G- 80286 instructions   Q- Overflow checking    Y+ Symbol reference info
  I+ I/O error checking   R- Range checking
Memory sizes: -$M<stack>,<heapmin>,<heapmax>  (default: 16384,0,655360)

[howardpc]

There are many occasions when you definitely want no range checking.
For instance when you are doing a typecast for which the compiler would flag a range error (the compiler has to assume a worst case scenario) but which you know -- given the data range your program handles, of which the compiler is unaware -- is a perfectly safe typecast.
Or for production code of tested and debugged routines which should not be slowed down and bloated by unnecessary range checking code.

So the default is a sensible choice for such common situations. In the development phase of new software you are stupid, of course, to omit range checking. But all it takes in Lazarus is one tick in a checkbox on the debugging page of your project options. Great safety gain for minimal effort.

[Kays]

[…] I was accidentally trying to print 9 elements, and as no error was generated, it must be that no range checking was done.

That's (also) why you always use high() (and low() [in conjunction with non-dynamic arrays]).

So, do-you-think-it-strange-too that the default is range checking OFF? […]

At first I scratched my head, too. It is clearly in violation with the relevant ISO standards:

A value of type T2 shall be designated assignment-compatible with a type T1 if […] T1 and T2 are compatible ordinal-types, and the value of type T2 is in the closed interval specified by the type T1. […]

[…] it shall be an error if T1 and T2 are compatible ordinal-types and the value of type T2 is not in the closed interval specified by the type T1;

I agree with the point, that range checks cost some time, time you don't necessarily always have to spend, since you know it'll be within the range. But I guess, it's within the permission to omit error detection where it would be, quote unquote, “an excessive burden.”

[Martin_fr]

Off course there are merits to turn it on or off, or even have the option to do so.... But that is not the question.

The question is what should be an expected default.
And IMHO that should simply be consistent with other settings. I would say for a debugging set-up, range check should be an included default.
For a release setting this may not be as straight forward. But I would say off.

I don't know what currently the defaults are, an a freshly installed Lazarus.
Nor what they are after you created debug and release build modes.

[PascalDragon]

So, do-you-think-it-strange-too that the default is range checking OFF? […]

At first I scratched my head, too. It is clearly in violation with the relevant ISO standards:

A value of type T2 shall be designated assignment-compatible with a type T1 if […] T1 and T2 are compatible ordinal-types, and the value of type T2 is in the closed interval specified by the type T1. […]

[…] it shall be an error if T1 and T2 are compatible ordinal-types and the value of type T2 is not in the closed interval specified by the type T1;

Turbo Pascal, Delphi and the non-ISO modes of FPC have no obligation to be ISO compatible, in fact the FPC mode leans towards compatibility with Turbo Pascal, while the ObjFPC mode leans towards compatiblity with Delphi which both don't have such checks enabled by default either.

[Kays]

[…] Turbo Pascal, Delphi and the non-ISO modes of FPC have no obligation to be ISO compatible, […]

Of course not, but turning off range checks in general (per distribution) just doesn't align with Pascal's paradigm to prevent the programmer doing stupid things. It's the same issue with {$boolEval}.

PS: And {$mode extendedPascal}. Both {$mode ISO} and {$mode extendedPascal} should conform to their corresponding ISO standard.

[graemejc]

The default modes, both for Lazarus and FP/FPC, are a compromise between what could be termed "heavy debugging" and "full release" modes, so it adds a little debugging info but doesn't sets on the full-checking "artillery".

And if you're showing your age, I guess most of us do: I was also a little startled when I discovered it.

Do note, though, that the default configuration for Turbo Pascal also had range checking turned off:

Code: [Select]

Borland Pascal  Version 7.0  Copyright (c) 1983,92 Borland International
[... compiler options ...]
Compiler switches: -$<letter><state>  (defaults are shown below)
  A+ Word alignment       K+ Smart callbacks      S+ Stack checking
  B- Full boolean eval    L+ Local debug symbols  T- Typed pointers
  D+ Debug information    N- 80x87 instructions   V+ Strict var-strings
  E+ 80x87 emulation      O- Overlays allowed     W+ Windows stack frames
  F- Force FAR calls      P- Open string params   X+ Extended syntax
  G- 80286 instructions   Q- Overflow checking    Y+ Symbol reference info
  I+ I/O error checking   R- Range checking
Memory sizes: -$M<stack>,<heapmin>,<heapmax>  (default: 16384,0,655360)

Thanks for that, especially the information re: the other modes. Important to know.


Is Pascal still taught at universities? To the best of my knowledge, in Australia, no. If not, does that mean that most on this forum, using freePascal are "oldies."

[dbannon]

Is Pascal still taught at universities?

Not that I know of (in Oz). RMIT was using in in the 1990's

Mind you, we do see a number of questions asked, from time to time, that pretty obviously relate to first year assignments ......
 

To the best of my knowledge, in Australia, no. If not, does that mean that most on this forum, using freePascal are "oldies."

Guilty as accused Your Honour !
Davo

[PascalDragon]

[…] Turbo Pascal, Delphi and the non-ISO modes of FPC have no obligation to be ISO compatible, […]

Of course not, but turning off range checks in general (per distribution) just doesn't align with Pascal's paradigm to prevent the programmer doing stupid things. It's the same issue with {$boolEval}.

Enabling these options by default in the modes that provide compatibility for TP and Delphi code is simply inviting unnecessary bug reports of users that complain that their code compiles/runs in TP/Delphi without any problems.

PS: And {$mode extendedPascal}. Both {$mode ISO} and {$mode extendedPascal} should conform to their corresponding ISO standard.

Feel free to submit bug reports if those two modes don't adhere to their corresponding standard.