[Pkg-pascal-devel] Status of FPC with hardening

[Michalis Kamburelis]

Thanks for the description! All good, so I know what to expect as an upstream.

>> Note that CGE does support debug and release modes of compilation, and
>> we fully support compiling the CGE codebase with range checking,
>> overflow etc. enabled.
>
> One day, we may try to take advantage of such FPC feature to ensure code is 100% safe. However today this is not the case.
> Also, one argument to disable such a feature that was the default in TP7, was the speed reduction due to checks overhead. However this is tiny compared to Python or Java overload. So maybe FPC is a good candidate to become the next safe coding language!

Note that the overhead of additional range/overflow checks *can* be
still very significant in Pascal. It depends a lot of the use-case,
but in certain CGE code parts the "debug" version (with all checks)
was even 1.9x slower than "release" (no checks, and optimizations
"on"). We documented this on
https://castle-engine.io/manual_optimization.php#section_release_mode
.

So, in CGE:

- we recommend to use "debug" builds for all the testing,
- and I definitely recommend to write all Pascal code to work with
range/overflow checks "on" (I wrote about hem on
https://github.com/michaliskambi/modern-pascal-introduction/wiki/What-are-range-and-overflow-checks-(and-errors)-in-Pascal
).
- ... but for "final" builds, for users, we do recommend to use
"release" options, that disable the checks.

I'm not saying that speed is more important than security, but I'm
saying that they unfortunately sometimes conflict, and the right
decision depends on the situation :) E.g.

- for single-player games that don't read any input from the Internet,
it may be preferable to run at 60 FPS than have additional checks (for
potential bugs) and only 30 FPS.

- But for a tool like castle-model-converter, that is commonly run on
an "untrusted" input, it's probably better to have all the checks
"on", in case we've made some error. At least some bugs are then
crashes, and not serious security issues due to buffer overflows, as
you mentioned.

>>
>>  But this is not 100% true for all Pascal code,
>> I recall some FPC RTL code that was doing tricks and just assuming
>> that range checking is off, otherwise an "innocent" (actually valid)
>> code will raise range errors.
>
> That code is generally not portable over architectures.

Sometimes it is not portable, sometimes is may be proven (to humans,
but not to a compiler) to be valid and even portable. E.g. this is a
convoluted but valid code, but it will make range check error with
$R+:

"""
type
  TMyArray: array [0..0] of Single;
  PMyArray = ^TMyArray;
var
  Values: array [0...1000] of Single;
begin
  PMyArray(@Values)^[100] := 3.14; // convoluted but valid way of
doing Values[100] := 3.14;
end;
"""

Similar, code below will raise overflow with $Q+, but the programmer
may be OK with deliberate "overflow behavior on uint32" in this case:

"""
var
  I: Integer;
  Sum32: LongWord;
begin
  for I := 1 to 1000 do
    Sum32 := Sum32 + 1000 * 1000 * 1000;
end;
"""

I mean, I still recommend to avoid such code or at least openly
document that you really must depend on range/overflow off. We have in
CGE {$I norqcheckbegin.inc} / {$I norqcheckend.inc} for this purpose,
used like https://github.com/castle-engine/castle-engine/blob/8ce77b04e4420cfd4b9032aff43e7e883eaa8824/src/audio/openal/castleopenalsoundbackend.pas#L665
, https://github.com/castle-engine/castle-engine/blob/8ce77b04e4420cfd4b9032aff43e7e883eaa8824/src/base/castlerenderoptions_renderoptions.inc#L556
. So the units can be compiled with range/overflow "on" and the checks
are only selectively disabled. And it would be better to not ever even
use {$I norqcheckbegin.inc} / {$I norqcheckend.inc} at all :)

But various Pascal code may have different opinions, some codebases
are not 100% tested for range/overflow always "on". ( Though it would
be appropriate for me if Debian would try to force it! As an upstream,
I would agree. But it would need cooperation from all upstreams. )

OK, sorry for the long answer, I got talkative, and I don't have any
point in all this :), just wanted to provide some extra information.

Regards and good weekend,
Michalis