[lazarus] New Bug Entered

Michael Van Canneyt michael.vancanneyt at wisa.be
Mon Jul 14 10:33:10 EDT 2003




On Mon, 14 Jul 2003, Mattias Gaertner wrote:

> On Mon, 14 Jul 2003 16:13:33 +0200 (W. Europe Daylight Time)
> Michael Van Canneyt <michael.vancanneyt at wisa.be> wrote:
>
> > [..]
> > > > > One correct solution is to create better "empty procedures". This
> > > > > means an empty procedure, with the right length of parameters. I'm
> > > > > not sure how to do this for all kinds of calling conventions and
> > > > > processors.
> > > >
> > > > You can't.
> > >
> > > Why that?
> >
> > Because the callee clears the stack. This is unlike C, where the caller
> > knows how much is pushed on the stack, and removes exactly this amount.
> > in FPC, the caller expects a certain amount on the stack, and removes
> > this amount from the stack, irrespective of whether this amount was
> > indeed pushed or not.
>
> Then you mean: You don't see a way to do this easily.
> It will only be impossible, when a processor does not allow to execute code
> in data mem.

Yes, but implementing such things is very bad coding IMHO.

>
>
> > [..]
> > >   MyDataModule.AnNotifyEvent:=TNotifyEvent(@MyDataModule.SimpleProc);
> > >
> > > A simple
> > >
> > > AnNotifyEvent(Self)
> > >
> > > works (at least on i386). But a
> > >
> > > try
> > >   AnNotifyEvent(Self);
> > > except
> > > end;
> > >
> > > does not work.
> >
> > Of course not, since the stack is messed up.
> > The exact error will depend on the particular code.
> >
> > The way I see it is that during design time, NO callbacks may be set.
>
> Right. But NO really means NO. If an event is set at any time, it can be
> called and destroy the stack.

Normally not, as the compiler should do type cheking on assignment statements.
It's only because this 'TMethod' record is used that the type checking is lost.

> > This also means that you must
> > - After form load, replace all filled in event handlers with nil, and
> >   keep a record of this.
> > - In the object inspector, show the 'fake' record which you saved.
> > - When creating new events, put them in fake records.
> > - Before form saving, fill all callbacks again
> > - after form saving clear them again.
> >
> > The best way of doing it IMHO is to make descendents of the
> > TReader/TWriter which do this automatically, and which also keep the
> > list of 'fake' records.
>
> Ok.
> There are enough other good reasons to improve TReader/TWriter (better error
> handling, interactive reading). But Borland wrote TReader/TWriter in a very
> closed way. Not enough virtual methods and it uses a lot of private
> variables. Of course we can use the workarounds you mentioned, but it would
> be much nicer, to open TReader/TWriter for extensions.

I'm all for that. Feel free to propose/implement improvements.

Michael.






More information about the Lazarus mailing list