Yes, and if length were always respected we would not have all these buffer underruns in C. As I said: "if done properly"... "When things can go wrong they will go wrong." Or: "Never change a winning team".
I did a lot of these micro-optimizations myself with arguments like "it looks better when I do it this way", "ah, this is a bit faster" etc., and I almost always ended up in introducing a bug somewhere. This is different from fixing a bug. A bug MUST be fixed, micro-optimizations gains nothing.
That is the problem with pchar
It is very unsafe, and easy to accidentally use a wrong length
But with a sub string type, it would store the length together with the pchar, so you cannot use the wrong length. The example
In fpreport.pp: SameText(Copy(BaseName,1,9),'TFPReport')
would be changed
In fpreport.pp: SameText(CopyAsSubStringView(BaseName,1,9),'TFPReport')
and is faster, and still safe.
Or with type helpers, one could do:
In fpreport.pp: BaseName.SubStringView(1,9).SameText('TFPReport')
It is safe, faster and looks better
If a function is not used in your program then it will be smartlinked out, especially if you did indeed enable the smartlink options. If it is not left out then it is indeed used either directly or indirectly.
That did not work at all
Looks like -gl disables smartlinking