[fpc-devel] Const optimization is a serious bug (What nexy)

[Hans-Peter Diettrich]

Martin schrieb:

>> c) keep the current behaviour, but add functionality to the compiler 
>> to help debug problems that can occur as a result of problems that can 
>> occur as a result of this behaviour

Concrete: add means to ignore "const" with managed types.

Further debugging aids as far as feasable. Do we want to make FPC an 
outstanding compiler, WRT bug hunting? IMO *not* a realistic goal.


> Actually I think you can describe that as 3 independent proposals:
> 
> 1) Add a compiler switch or directive to disable "const"behaviour for 
> ref counted types (e.g. simply ignore "const" for 
> string/dyn-array/interface params; Actually downgrade, still prevent 
> assignment to local var)

+1

> 2) Add automatic optimization of dropping ref-count and exception frame, 
> if the compiler can prove it to be save (e.g.  no calls to any other 
> code...). This can happen completely independent of either the present 
> or meaning of const.

~ [people will point at you if it doesn't work perfectly :-]

> 3) Add safety checks (similar to range checks)

As a debug feature only, on demand (debugging memory manager?)


Most people don't have problems with const, according debug features are 
*not* an urgent requirement.

I only agree that a *quick workaround* (global "ignore const" option) is 
highly desireable (a *must*) for the rare (but real) cases where it can 
make runtime errors disappear.

Extended debug features are not so important, because code with such 
problems typically suffers from *general* problems, which suggest a 
change of the personal coding style. A compiler can prevent an user from 
shooting himself into one foot, at best, but not prevent him from 
shooting himself into other limbs :-]



> 3)
> Might not only help to fix issues, but might also create awareness.

This may apply to newbies, but IMO will be ignored by people which 
*believe* that they are superior coders, maybe from practice in other 
languages. A collection of suggested design patters (resource 
protection, object ownership...) would be nice - in detail for pointing 
people with coding style problems to. We could add to that collection 
all demo code, that forces unexpected exceptions, together with a safe 
version of the same code, that eliminates the demonstrated problem.



> If an exception frame already exists (even if on a higher stackframe), 
> and the compiler can detect that it does exist:
> then instead of creating an exception frame for the current stackframe, 
> all the variables that need refcount decrement, can be added to a list. 
> This list can be processed by the exception handler, before any other 
> code executes. The draw back is, that memory needs to be allocated for 
> this list.

IMO this is what the compiler already does, or should do - an implicit 
try-finally block with a list of variables to be finalized on exit of a 
subroutine (used also in stack unwinding after an exception). One should 
not confuse try-except (*handling* exceptions) and try-finally 
(guaranteed *cleanup*).

DoDi