oswordreadclock_utc

[David J. Ruck]

On 9 Jul 2001 Tony van der Hoff <tony at mk-net.demon.co.uk> wrote:
> > My question is, should oswordreadclock_utc and its related functions
> > xoswordreadclock_local_string, xoswordreadclock_local_bcd,
> > xoswordreadclock_convert_bcd_to_string and the equivelent write clock
> > functions set up the reason code in the block themselves? 
> > 
> They are presently not intended to, although I agree that this might be a
> desirable feature. The problem is that, at present, DefMod has no way of
> initialising data structures (as opposed to registers). The OSLib veneer is
> simply too thin to handle such concepts. The user is expected to supply any
> data structure fully initialised.

Ok, thats fine, I dont mind putting in the code to do this myself (the
solution was only one extra line). 

> but don't really see where it would be appropriate to describe this
> behaviour in the Stronghelp manual, or the C headers. You have made a
> reasonable, but incorrect, assumption about OSLib behaviour.

I think it does need to be made clear in the headers and StrongHelp that data
blocks should contain the relevant reason code, after all it mentions
register contents during the call, so not mentioning data can lead to
problems like mine. I dont think I can be the only person this has happened
to - if so I'll let it lie :-)

> My present feeling is that whilst it would be nice to get OSLib to do this
> initialisation where possible, the number of applicable API calls, and
> therefore the potential benefits of doing this, is very limited. They are
> mostly OS_Word and OS_Byte calls, which are gradually being superseded in
> any case.

I agree, it would only be a small number of calls, and only those where a SWI
is split into seperate functions for constant each sub-reason code. It does
make sense to bring inside the library any initialisation which is always
required, as otherwise the code has to be repeated each time:-

    utc.op = oswordreadclock_OP_UTC;
    oswordreadclock_utc(&utc);

> I wonder whether it might not be better to hive this sort of
> functionality off to OSLibSupport, rather build it into the core library.

I think that would start getting confusing if there was one call that did
initialise and one that didn't.

> Whilst not a valid reason for not changing things, I must confess I have no
> idea as to how to change DefMod to accommodate this, although I've not
> looked into it very deeply, it is certainly not trivial. Perhaps more
> knowledgable DefMod experts than myself can comment? If there is enough
> support, and no serious objections for such a change, I'm quite happy to
> see what can be done. Naturally, any other comments are most welcome.

Well on the upside at least making this change would be backwards compatible,
as I think we can assume that anyone intialising the reason code to something
different to what the call expects is a bug, and by doing the init withing
the function, you'd actually be fixing a bug in a program, which is quite
an appealing proposition.

Cheers
---Dave

-- 
____________________________________________________________________________

  David J. Ruck    Phone: +44- (0)7974 108301    Email: druck at freeuk.com
____________________________________________________________________________