Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!bagate!cbmvax!cbmehq!babylon!rbabel
From: rbabel@babylon.rmt.sub.org (Ralph Babel)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Information on Amiga Technical Reference Seri
Message-ID: <08545.AA08545@babylon.rmt.sub.org>
Date: 17 Jun 91 18:44:49 GMT
References: <3036@public.BTR.COM> <VINSCI.91Jun14003452@nic.nic.funet.fi> <22455@cbmvax.commodore.com> <3096@public.BTR.COM>
Reply-To: cbmvax.commodore.com!cbmehq!babylon!rbabel (Ralph Babel)
Lines: 42

In article <3096@public.BTR.COM>, valentin@public.BTR.COM
(Valentin Pepelea) writes:

> Nobody in his right mind would start using tricks or
> undicumented features that would break their software in
> the future.

As you said: "in his right mind" ... :-(

> Besides, we all have a constitutional right to shoot
> ourselves in the foot.

America the Beautiful! :-)

> On the contrary, the error was produced by the lack of
> documentation and a significant error in OS design.
>
> Regular device IO requests have their input fields
> preserved.

If you are talking about the actual implementation, you may
be right. If you are talking about the _definition_, you are
definitely wrong! The 1.1 Exec documentation only guarantees
io_Device, io_Unit, and io_Command to be preserved. It does
not say anything about other input field, such as io_Flags,
io_Length, io_Data, and io_Offset (even though it _does_
say: "This permits repeated I/O using the same request.").
The 1.3 documentation explicitly allows a device driver to
modify these latter fields.

Btw: I'd also consider this a design mistake, but this point
is completely moot.

> And then there are questions which will never be answered,
> particularly not on Usenet. Like, is there a bug in
> function XXX?

I agree; this is a serious problem! Commodore might
acknowledge the existence of a specific bug, but a list of
known bugs has yet to be published.

Ralph