No subject

You can use the _ _cdecl, _ _pascal, _ _fastcall, or _ _stdcall keywords to
override the default calling convention on specific functions.


__cdecl is standard C call (where caller fixes up the stack)
__pascal is pascal call (where callee fixes up the stack)
__fastcall is where registers are used to pass parameters whenever possible,
and callee fixes up the stack
__stdcall is where no underscores are generated, called function fixes up
the stack.


----- Original Message ----- 
From: "Michael Van Canneyt" <michael.vancanneyt at wisa.be>
To: <lazarus at miraclec.com>
Sent: Monday, July 14, 2003 11:15 AM
Subject: Re: [lazarus] New Bug Entered


>
>
> 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.
>
> _________________________________________________________________
>      To unsubscribe: mail lazarus-request at miraclec.com with
>                 "unsubscribe" as the Subject
>    archives at http://www.lazarus.freepascal.org/mailarchives