Mail Archives: djgpp-workers/2000/08/17/12:56:21
> Date: Thu, 17 Aug 2000 16:42:19 +0200
> From: Laurynas Biveinis <lauras AT softhome DOT net>
>
> Eli Zaretskii wrote:
> > In the latter case, __FSEXT_call_open_handlers will not do,
> > because it searches the wrong list of handlers.
>
> Correct me if I'm wrong: if user adds FSEXT for a particular
> handle, then this function won't call its handler, it will call
> readlink handler as an 'open' handler, right?
Yes, it will.
However, imagine that there are other handlers for other FSEXTs as
well. Those other handlers might (1) not be ready to cope with a NULL
pathname, and (2) one of them might intercept the call before the
readlink handler gets a chance (because of the order of registration
of the hooks, upon which FSEXT doesn't give the application too much
control).
In other words, if a certain handle has a handler registered, that
handler should be called unconditionally and immediately, without
trying the other handlers which might mistakenly catch a call whch
isn't theirs. __FSEXT_call_open_handlers cannot do that, but
__FSEXT_get_function can.
> So I have to call single handler in two ways: this -
>
> if (func(__FSEXT_readlink, &rv, &blah, &blah,...))
> return rv;
>
> and this:
>
> if (__FSEXT_call_open_handlers(__FSEXT_readlink, &ret, &__path))
Yes, that's what I thought about.
> Will the same handler do well in both cases?
I hope so. Do you see any reason why it couldn't? Do they have
different signatures or something?
> When it comes to FSEXT, I feel less confident.
Me too ;-).
- Raw text -