Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!dali.cs.montana.edu!caen!spool.mu.edu!uunet!lll-winken!aunro!alberta!herald.usask.ca!telepro!tptbbs!Jeff_Petkau From: Jeff_Petkau@tptbbs.UUCP (Jeff Petkau) Newsgroups: comp.sys.amiga.programmer Subject: CreateTask Message-ID: Date: 5 Jun 91 03:31:52 GMT Organization: TelePro Technologies Lines: 33 In a message dated Mon 03 Jun 91 05:00, Phorgan@cup.portal.com (Patrick John Horgan) wrote: PH> I couldn't post my original hack of CreateTask, since it was based on PH> Manx's source, but I did another based on the one in the Revised and PH> Updated Includes and Autodocs manual. The only difference between this PH> and the one in the Includes and Autodocs is the memory is allocated for PH> the name, and a copy is made of the name so that it will be reentrent. ... PH> ml = (struct MemList *)AllocEntry((struct MemList *)&fakememlist); PH> if(!ml) PH> return(NULL); This is something I've been wondering about for a while now. In the 1.3 Includes & AutoDocs, it says of AllocEntry: "If enough memory cannot be obtained, then the requirements of the allocation that failed is returned and bit 31 is set." In other words, AllocEntry does _not_ return NULL on failure, and any code that assumes it does is in ghastly trouble when memory gets low. But in 1.3 Libraries & Devices, and in all the compiler libraries I've bothered to look at, CreateTask() does this very thing. So: is AllocEntry() misdocumented (after all, the documented behaviour is pretty damned silly), or has CreateTask() been broken in every single OS release to date, or am I just very confused, or what? -- Via DLG Pro v0.975b BONKBONKBONKBON I mean, the whole purpose of my existence is to O Jeff Petkau K serve you with hot buttered scrummy toast. N BONKBONK if you don't want any then my existence is K petkau@tptbbs.UUCP N meaningless. I toast, therefore I am. BONKBONKBONKBONKBONKBO - The toaster on Red Dwarf