[fpc-devel] Const optimization is a serious bug

[Martin]

On 07/07/2011 17:36, Alexander Klenin wrote:
> On Fri, Jul 8, 2011 at 03:23, Martin<fpc at mfriebe.de>  wrote:
>
>> Yes, I use pointers, but it does not matter how I managed to change the
>> content of "s". All that matters is, that I broke the promise (assuming s
>> was declared const")
> No, the whole point it is that it *does* matter.
> Direct memory access lets you break anything --
> class members' visibility, callstack frames,
> built-in data structures like vtables, exceptions, refcounting, anything at all.
> That does not mean all those features are useless and we should go back
> to programming in assembler.
> That also does not mean we should allow arbitrary breakage of those
> features since "you can break them anyway".
>
> After all, you can break any string code the code much simpler:
> (PInteger(s)-1)^:=-1;
>


ok, so  ansistring are the exception (or at least I will not search for 
further ways), because their copy-on-write adds an extra layer of 
protection.

but it still doesn't help.

Florian showed that the problem exist for ShortString.

In many cases the difference between ansi and short string s $H+/-.
Which means you move the breaking of your code into a compiler switch.

And also the example with the cached evaluation, would also apply to 
let's say records.

So in your scenario, the "const param" would then mean:
- const x: record => a promise not to modify the original record, or 
else you risk crashes and other errors
- const s: string => no promise, so you can do what you want

That doesn't make much sense either. Now const means different things 
depending on the type ?