Import of InfoZIP

Ian Jeffray 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 ?
>>>
>>Yes, below.
>>
>>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.  :-)

Ian.





More information about the gcc mailing list