e x e c . l i b r a r y                                         FindTask 
__________________________________________________________________________
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

REPORT          Forbid() missing, unreliable result

SEVERITY        Level 2

EXPLANATION     If you search for a task by its name, you MUST freeze
                multitasking before searching through the public task
                list. Otherwise the task could be removed shortly after
                you've got the pointer. Any access to the TCB will then
                throw Enforcer hits in best case, or it will just trash
               memory.

                Anyhow, FindTask(NULL) will work fine even with enabled
                multitasking. This is because there is no iterating
                through the public lists of tasks required to find the
                own task, and if you can use the result, you'll surely
                be still alive... ;-)

DEADLY          In DEADLY mode, this function call will return the
                true return code only if multitasking was forbidden
                or NULL has been passed as task name. Otherwise it will
                return NULL if the task really wasn't there, or
                0xFACEDEAD if the task was found. So, just finding out
                if this task existed will still work, but accessing it
                will cause Enforcer hits.

REMARK          Some people claim that this hit is annoying, since they
                consider this practice to be legal if you only want to
                find out if a port is available or not.

                I don't think so. There is still a slight chance to
                crash the system. Imagine your program is iterating the
                list without Forbid(), looking for a certain Node B
                which comes after Node A. Now, while FindPort() is
                fetching Node A, a scheduling occurs and another process
                gets the processor. This other process now removes Node A
                from the list and changes its memory contents. If your
                program then gets the processor back, it will get a
                completely messed up 'Node A', and will crash.

                It is sad, but as long as AmigaOS does not provide a
                semaphore mechanism for public lists, we must use Forbid()
                if we iterate through them.