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

_______________________________________________
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply via email to