Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!cornell!batcomputer!itsgw!steinmetz!ge-dab!peora!rtmvax!johnc
From: johnc@rtmvax.UUCP (John Connin)
Newsgroups: comp.os.minix
Subject: A word of caution.
Keywords: Minix
Message-ID: <1873@rtmvax.UUCP>
Date: 25 Aug 88 18:20:16 GMT
Organization: Robert Talley (PRIVATE), Orlando, FL
Lines: 31

In article  <1119@ndsuvax.UUCP> ncoverby@ndsuvax.UUCP (Glen Overby) writes:

> and cranking MAX_WIN_RETRY all the way up to 65535 (I guess the board is
> a bit slow).  Tell us when you get it to work!

Be careful, you may have introduced a bug waiting to happen -- and if
it happens your system will hang. I was not able to quickly put my fingers
on xt_wini.c however, but at_wini.c has the follow construct which I will
assume is similar to xt_wini.c.

        register int i;
        int r;

        if (drive_busy()) return(ERR);

        for (i=0, r=0; i<MAX_WIN_RETRY && (r&8) == 0; i++)
                port_in(WIN_REG8, &r);

The point being that if MAX_WIN_RETRY is larger that 32767 the for-loop
exit condition may never be satisfied, and if not satisfied the system
will hang.  Reason, wini is a kernel task and thus not subject to preemption.
F9 will not even break you out of this one.

This situation suggests that it might be prudent in the above and similar
instances to (a) change 'i' to unsigned int or (2) add a warning comment
to the _limit_ definition.

On a related note, I noticed some mention of TURBO-C in recent articles.
Since TC seems to be a sensitive 'lint', perhaps it would be helpful for
someone to send AST a listing of all warnings produced by TC when compiling
minix code.