On 07/07/2011 17:36, Alexander Klenin wrote:
On Fri, Jul 8, 2011 at 03:23, Martin<f...@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 ?
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
