Import of InfoZIP
ian at jeffray.co.uk
Wed Dec 19 04:44:06 PST 2001
Paul F. Johnson wrote:
> In message <a32e47eb4a.peter at moo.chocky.org> you wrote:
>>In message <Pine.LNX.4.33.0112191039570.21520-100000 at dsvr.ds.dsvr.net>
>> Nick Burrett <nick at dsvr.net> wrote:
>>>Is there an updated SharedUnixLib module to go with this patch ?
>>Unfortunately, since this was finished in the wee hours, no one but me
>>has tested it. I'll put up a binary here:
> Downloaded and runs fine here on the RPC and RS machines.
It may run fine, but I'm afraid I may annoy Peter by saying I don't
think the design is best as it provides no obvious way to expand the
module to have any real workspace as the workspace pointer [r12] is used
as the head of the linked list of upcall handlers. Not the best basis
for a "SharedUnixLib" module, but fine for an "UpcallHandlerBodge" module.
The relationship between the r12 passed to the upcall handler and the
module's workspace pointer (it's private word) is too tight. To fix
that, a large-ish rewrite of the module would be needed.
Once we start having parts of unixlib that the user could (and no doubt
will) mix-and-match then there's gonna be shedloads of backwards-
compatibility issies. Ie, they might have an older or newer module than
we were expecting at a given rev of unixlib when their app binary was
built. I think the way that works needs perhaps somewhat more thought
than just what's been whipped up now (we've been thinking hard for a while,
but never put a structure in place) and to imagine that it's correct
right off could be a mistake. We're leaving our cosy all-or-nothing
library world and I forsee large dragons.
This is, of course, just my personal opinion. Flame on. :-)
More information about the gcc