OSLib 6.70 released

[Erik Groenhuis]

On 3 Aug 2004 Tony van der Hoff wrote:

> Tony van der Hoff <tony at mk-net.demon.co.uk> wrote in message
> <gemini.i1vcdx04b8zpc02j6.tony at mk-net.demon.co.uk>
> 
> Well, ISTM that event_poll(_idle) just call Wimp_Poll(_idle), passing on the
> parameters.

It does so in OSLibSupport. It does not in Acorn toolbox library.

> So the crash is nothing to do with the poll word pointer; this
> can quite happlily be NULL (provided mask bit 22 is 0)

Indeed, when the programmer wants to use the poll word (as indicated by
bit 22 being 1), he must pass a valid poll word pointer. No difference
between OSLibSupport and Acorn toolbox lib here.

> However, passing it a NULL for the poll block pointer seems a bit of a
> suicidal thing to do, and I can't see that working in Acorn's event library
> either.
>
> So, I see no bugs here...

Ah, there's the rub.

>From this I can deduce that you have never actually used the Acorn
toolbox library.

As illustration, from the !Hyper example, c.main line 229-231:
 
     while (!quit) {
        event_poll(0,0,0);
     }

This is a working example, often used by programmers as a base for
their own developments. The "Use Interface Toolbox" manual Chapter 2
"Building an application" uses !Hyper as an example.

Reverse-analysis of the library shows that:

- When the second parameter, poll_block, is NULL, a private block on
the stack is passed to Wimp_Poll.

- The first parameter, event_code, is tested before the event number is
written. The value is only written if event_code is non-NULL. (This of
course a precaution well-known to OSLib users and makers.)

The manual ("Acorn C/C++" Chapter 9: "The Event library", section
"Polling") actually *does* say poll_block should be allocated before
calling event_poll, but it does not mention the event_code pointer.

This only goes to show that the manual does not always tell the whole
story.

The main problem with omitting these tests from the event_poll() and
event_poll() idle routines in OSLibSupport is that programmers who want
to migrate from the Acorn toolbox libs to OSLib are in for a very nasty
surprise.

They may have dozens of programs they have been developing for years and
that compile and run without the slightest problem with the Acorn
Toolbox libs. At some point, they might get the idea that it would be a
good move to migrate to OSLib. Maybe a friend recommended it, maybe
they read good things about it, or maybe they got fed up with the
clumsy way of calling SWIs from C using _kernel_swi() or similar.

To migrate, they take one of their programs (preferably a simple one)
(or maybe someone else's) and modify it so it compiles without moaning
with the OSLib and OSLibSupport headers and links without moaning with
the OSLib and OSLibSupport libraries. Not always an easy job.

And when they try to run it: CRASH! (And usually a pretty nasty one
too: often the machine needs to be reset.)

This is very disappointing, after all that hard work to get the code to
compile and link.

This will reflect badly on OSLib. Their first reaction: "OSLib sucks".
(It's still too early for a fresh user of OSLib to make a distinction
between OSLib and OSLibSupport). Next reaction, after they discover the
cause of the crash: "The OSLib developers don't know what they are
doing. The don't even test the parameters of event_poll(). The rest
will probably be just as bad."

Unsurprisingly they give up on OSLib. And, what is worse, when someone
asks them about their experiences, they whole-heartedly recommend
against using it.

I'm not making this up. I experienced it first hand.

Coming Real Soon Now: suggested modification to Event.c

(On a final, more philosophical note: for a library such as OSLib where
pointers are *always* checked to avoid writing through them when they
are NULL, it is inconsistent to drop this check for a routine that is
merely part of a "support" library.)
-- 
Erik Groenhuis http://www.xs4all.nl/~erikgrnh
Home of RCS for RISC OS v5.7.1.2  http://www.rcs.riscos.org.uk/
Csite on RiscPC with a StrongARM RISC processor and RISC OS 4.02