arcweb_url / arcweb_urlw problem

[Jonathan Coxhead]

On 19 Nov 2002, at 10:45, Tony van der Hoff wrote:

> On 16 Nov 2002, in message <25605d964b.tom at compton.compton.nu>,
> Tom Hughes <tom at compton.nu> wrote:
> 
> > The 32 bit file handle changes have broken the Arcweb module.
> > 
> [snip]
> 
> Ouch!
> 
> As I see it, there are two solutions to this problem:
> 
> 1. Abandon the pretense that there are anything other than wide file handles in
> the arcweb module; there never are, and never will be. The idea was in any case
> only introduced for uniformity with the rest of OSLib. We can then dispense with
> arcweb_urlw and the macro translation from arcweb_url. It's the same thing
> anyway. This simplifies the world greatly :-)
> 
> 2. We keep the concept of uniformity, and introduce structures like
> arcweb_message_fetch_requestw, which takes a arcweb_urlw before translation, and
> then add a conditional translation in arcweb32.h from
> arcweb_message_fetch_requestw to arcweb_message_fetch_request, thus hiding all
> the messiness.
> 
> (1) makes things nice and simple, but breaks compatibility, although I can't
> imagine anyone has ever used arcweb_urlw. (2), OTOH, preserves compatibility,
> but makes things even more complex, and increases the header sizes slightly. On
> balance, I guess it's best to play safe and go for (2). What do you think?

   Looks like (1) to me ... trying to make something look uniform that never 
was is lying to the compiler. ("Never lie to the compiler ... it will take its 
revenge"---Henry Spencer.) Any feature that in the "best case" does nothing, 
and has a worst case where it causes harm, is a bit suspect in my book!

   There isn't any compatibility issue, really. All we are doing at present is 
introducing a narrowing in places where ArcWeb doesn't need or want it.

   So I think this would come under the "bug-fix" cause, where we don't mind 
breaking code, if that code was already broken.

        /|
 o o o (_|/
        /|
       (_/