[fpc-pascal] TIniFile crash/memory loss

[Michael Van Canneyt]

On Fri, 1 Apr 2011, Bart wrote:

> On 3/31/11, José Mejuto <joshyfun at gmail.com> wrote:
>> B> This however means that the programmer has to protect TIniFile.Free
>> B> with a Try..Except block, which is also rather unusual.
>>
>> It's unusual, but there is an error, or the class does not perform the
>> save in the free procedure and uses a "flush" (forced) or the class
>> must raise an exception as the expected job has not been performed.
>
> The job of the destructor, however, is to clean up the object and return memory.
> This should never fail IMHO.
>
> One could even argue that the whole call to UpdateFile in the
> destructor simply should not be there.
> If the user (programmer) takes the risk of caching the write updates,
> then it is the programmers responsability to make sure the cached
> values are written at some point.

The problem is Delphi compatibility.

If you use TMemIniFile, then you know that you must call UpdateFile.

When using TIniFile, however, Delphi uses the windows API. This makes sure that 
each write is automatically committed to Disk. (well, we hope so)

Since this is not portable, the FPC TIniFile in fact descends from TMemIniFile.
It should be compatible to Delphi's TiniFile, i.e. the programmer should not 
worry about 'updating the file', this should be done automatically.

There are 2 options then:

1. Do an UpdateFile after each write.

    This used to be the default behaviour, but is VERY slow because each write statement
    causes the entire file to be written to disk.

2. Cache the updates, and make sure they are written when the instance is destroyed.

    This is the current behaviour. It works fast, but the corner case you encountered
    (an error when updating the file in the destructor) is now an issue.

Going back to 1 is not an option. 
For case 2, I am inclined to say that the destructor must always succeed.
Errors in destructors are very ugly to trap.

Michael.