Forum > Options
Type checking of typed pointers, option -Sy, directive {$T+}
JuhaManninen:
The development version of Lazarus IDE now has "@<pointer> returns a typed pointer (-Sy, {$T+})" in Project Compiler Options, Parsing pane.
Please test and set it as default for new projects using the "Set compiler options as default" Checkbox at bottom left of the Project Options window.
Typed pointers do not have type checking by default when using the address @ syntax! It means the following code compiles :
--- Code: Pascal [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---var I : Integer; P : PChar;begin P:=@I;end.(That snippet is from FPC documentation.)
It feels almost like a bug in a strongly types language. -Sy or {$T+} brings type checking there. The above snippet fails to compile with -Sy, as it should.
-Sy finds real errors, for example :
https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/40265
Sometimes however valid code fails to compile and a fix makes it longer and harder to read. An example from a patch in issue :
https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/40263
--- Code: Pascal [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---- Polygon(DC, @Points, 4, False);+ Polygon(DC, @Points[Low(Points)], 4, False);"Points" is an array. Polygon() needs an address for its first element. "@Points" gives address for the first element but -Sy demands it explicitly with "@Points[Low(Points)]". It repeats the word "Points" and does not look as nice.
Is there a way to improve this?
Adding a Pointer() typecast makes everything compile but that is dummy and does not guarantee valid code. Then it is better not to use -Sy at all.
I hope "Arioch The" joins the forum discussion. He writes long endless rants in the bug tracker which is a wrong place for it.
It would be nice to make some packages / libraries compile with -Sy. LazUtils at least.
Martin_fr:
I guess this also affects pointer arithmetic.
E.g.
--- Code: Pascal [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---for i := 0 to sizeof(MyQWord)-1 do MySum := MySum + PByte( @MyQWord+i )^;
Will without typed pointer, add all the bytes in the QWord.
But with typed pointer it will add 8 times i bytes to the address (inc to the next qword). And then take the first byte of each of those qwords.
Both will compile. Just the result will be different.
Bart:
Why not add {$T-} to those units that depend on not being compiled with typed pointers?
(As long as current implementation, wiht typed pointers off, of course is correct.)
Bart
Arioch:
Sorry, i am really short of time there days.
Few changes i made that day while hoping it would be a low hanging fruit are https://gitlab.com/ariochthe/source/-/commits/win32api_fix
I wish the compiler added some help by https://gitlab.com/freepascal.org/fpc/source/-/issues/40275 and by extending the DLL "delayed loading", but i appreciate everyone is busy these days as exonomics goes down everywhere.
I would try to keep an eye, but i would not probably be active.
Would this be a low-hanging fruit... but it would be more like rolling Sisyphus stone againt FPC team and LCL team established practices. More duplication of code and efforts like at https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/39935
Why?..
One day BPL's would arrive and Lazarus would no more need FPC RTL (as sources) and we can have another look at this, perhaps.
----
> Why not add {$T-} to those units
Like i said in the tracker - it will destroy the very idea. This switch NOW has no big meaning - users for years were testing the implementation.
This switch has two merits:
1. helps to write FUTURE code with more safety
2. highlights the places that need code review
the goal 1 is solved by... "Adding {$T+} to the top of the unit"
the goal #2 exactly **requires** making the legacy code ALL compilable in $T- (unless there is a bug in compiler like in Delphi xe2)
Arioch:
Also, i admit i did a foolish thing by tinkering with "overrides" (but that is how we learn).
The options was there, just a page above (but also hard to find).
But here it seems to be another can of 22
The #3 screenshot is the project options for a package.
Sadly Laz IDE is designed in the asusmptiuon there is always exactly one EXE-project open, never less than one and never more than one. :-/
So the package - part of the IDE de facto - inherits some option from EXE (namely this -Sy override from #2 screensshot) - but does NOT show it and does NOT give user way to override it.
Actually, in an ideal world i should not run into all this, as all i was doing was back-porting the Juha's patch.
The package would NOT inherit the -Sy switch in such a world, would had recompiled, and i would never learn all the things spelled.
This hiding if the essential page for packages... there probably is the reason, but still it was very cvonfusing catch 22.
Also, i told in the trackeer about synchronizing options in two pages.
I still wish the -Sy box in the #1 screenshot would get automatically selected just because the -Sy was manually added to the Overrides.
And i think (can not test if maybe already is) the -Sy checkboix should be synchronized with $T+ checkbox Juha just added.
Navigation
[0] Message Index
[#] Next page