Well, that only comes into play, if the the "out param" is otherwise never written too.
No, because the code that implements the -gt switch will have corrupted the parameters before the user/programmer gets a chance to do it.
That is the entire intent of -gt.
If you have code, that may crash or misbehave (sometimes, or even rarely), -gt attempts to increase the change that this code will crash or misbehave.
The exact line is not guaranteed, but that is similar (at least in some cases) when it is a local var that was trashed.
Though I grant you, wish a trashed local var, the error usually happens either at or (far) after the access to that variable. And here it happen earlier. But still the goal is archived, you get an indication that something is wrong with your code.
So yes, if I declare an out param, to which I never write, then it is this switch that brakes my promise -> alternative reading: I broke the promise by using the switch.
No, the switch breaks the promise whenever the function/procedure is called with both arguments referring to the same variable. In that case, which is the case Serge has demonstrated, that switch breaks the promise before the user has a chance to.
Again, so what? Goal archived, the user knows there is an error. Better than shipping a broken app, and learn from your customer that it is broken.
[/quote]
What I'm going to say next is admittedly arguable but, it can be argued that Serge didn't break the promise at all since he is simply assigning the variable to itself. He doesn't change the value, the value remains constant. That said, I will be the first to point out and admit that just writing to what is supposed to be a constant is questionable but, that's what -gt does and it does it without respecting the value of what is supposed to be constant.
[/quote]
Ok, that is somewhat valid. (Except for refcounted types, because the assignment may change ref counts)
I am somehow not sure how far that will carry as an argument to get a {$GT-} directive (which is what would be needed in that case)
But if I declare an out param, I am likely to write to it, am I not? (Yeah, other cases can be constructed, like check that the const param is different before writing the out param / But even that breaks, see my prev post).
If indeed I am writing to the out param, the all -gt does is, it pulls the broken promise to the top of the procedure, so it is easier to spot.
No because the programmer isn't creating a problem by writing the same value onto itself (the promise is kept that way). -gt on the other hand, tramples on the constant by overwriting it with an arbitrary value of its choice.
<repeated>
This is a typical pointer aliasing problem and -gt a priory assumed that there was no aliasing. What it does _depends_ on the parameters not being aliased, whereas what Serge is doing does not. He is writing to a const (which is admittedly questionable) but, unlike the -gt switch he preserves the value which meets the essence of the promise made to the compiler.
Again not for refcounted types.
But yes the doc currently states "will not be changed". So maybe that should read " will not be written to"
E.g if I have "const A=5;" I can not later in code do "A:=5" even though it would not change the value of the code.
Anyway I can only guess here....
I remember the "const param" docs had to be updated before, because they where not accurate enough. But maybe this time they are... I don't know that.
A compiler should not assume that a pointer and a variable or two pointers are not aliases of each other unless it can deterministically determine they are not. Serge's procedure call is perfectly valid, the assumption made by the -gt switch isn't, thus leading to an incorrect result.
That behavior of the -gt switch is, and should be considered a bug. It unwarrantedly assumed that the parameters are not aliases of each other thus causing a problem.
Well, 50% disagree.
That is, it is a bug, but it might be a bug in the doc. It may be that this behaviour is missing from the doc. But I did not design it, so I can not say what the intend is.
And again, if passing in a ref counted value in this Test function, then it may be that the problem happens even without -gt. Again I dont know what the indent here is.
But previous discussions on the "const param" left me with the impression, that it is meant to leave all burden to the user. (simple stating this, not judging it)