Import of InfoZIP

Ian Jeffray ian at
Wed Dec 19 04:44:06 PST 2001

Paul F. Johnson wrote:

> In message <a32e47eb4a.peter at> you wrote:
>>In message <Pine.LNX.4.33.0112191039570.21520-100000 at>
>>          Nick Burrett <nick at> 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.  :-)


More information about the gcc mailing list