[fpc-devel] Const optimization is a serious bug

[Aleksa Todorovic]

On Sat, Jul 9, 2011 at 18:12, Chad Berchek <ad100 at vobarian.com> wrote:
> Wow, thanks for the insults guys. I didn't realize I was so stupid.
>
> You missed my point too, BTW. According to the link given:
>
> "A constant argument is passed by reference if its size is larger than a
> pointer."
>
> So you always know what the size of a pointer is? If I have this record:
>
> TMyRec = record
>  I: Integer;
> end;
>
> Is that passed by value or ref? Is someone compiling on 32-bit or 64? You
> don't know, and neither does anyone. And that is my point about why having
> it defined is important.

"Native pointer size" is exact term, because size of native pointer on
each platform is known and fixed (will not change in the future). I
don't know all of those sizes, but that is whole other point, and
should be (if needed at all) fixed in documentation, not language.


> I can't even remember the last time I used C++. My point in mentioning it
> was only to demonstrate by analogy what could happen if the same ambiguity
> present in the Pascal construct was present in other well-known languages.

It's not that easy to compare Pascal const with C++ const, because in
C++ there are other const language elements: const variable, const
function result, const object method, const object field (on top of my
head).

Just to mention that C++ suffers from the same problem as Pascal on
this matter. C++ doesn't have built-in refcount-ed types, but if you
use refcount-ed types, you need to take care of the exactly same thing
as in Pascal - you have to choose: either to enable refcount-ing (and
make your code safe and slower), or disable it (and make your code
faster but possibly unsafe).


> All the argument that such "bug" could exist with shortstrings and records
> as well is because nobody can say for sure whether they are supposed to be
> passed by value or by ref--it could be either. With constref, there is no
> ambiguity. You know it will be by ref, hence there is no question as to
> whether it's a bug. Otherwise it's just a matter of opinion.

As mentioned above, behavior of compiler is very well defined. If you
use var or constref, parameter is passed by ref. If you use no
keyword, parameter is passed by value. If you use const, it's
compiler's (well defined) decision.


> I guess my brain is way to tiny to get past the notion that a "write once,
> compile anywhere" programming language should be defined in such a way that
> the meaning of the program doesn't spontaneously change depending on the
> compilation platform.

Just checked

http://www.freepascal.org/docs-html/ref/refsu58.html

and it doesn't mention optimization of const refcount-ed parameters
(and possible problems), but Michael already said he plans (if I
followed discussion correctly) to update documention on this matter.

On the other hand, that page explicitly mentions that it is compiler's
decision weather const parameter will be passed by value or by
reference. Whatever choice compiler makes, your program will not work
(only) if you make semantic mistake (in problematic corner case, your
program will either crash ugly, or it won't work correctly).


Maybe Pascal needs 'constval' keyword? It would always pass parameter
by value, but it would reject assigning new value to this parameter.


Another (possible) solution is to add new behavoir to const
refcount-ed parameter, with the following rule:

- When local variable or local const parameter is passed to some
function's const parameter, optimization takes place, and there is no
increase of refcount. In all other situation (when you pass object's
variable, global variable, non-const parameter), refcount is increased
on the caller side.


Regards,
Aleksa