Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site ut-sally.UUCP Path: utzoo!watmath!clyde!burl!ulysses!gatech!seismo!ut-sally!std-unix From: std-unix@ut-sally.UUCP (Moderator, John Quarterman) Newsgroups: mod.std.unix Subject: limits Message-ID: <3576@ut-sally.UUCP> Date: Tue, 19-Nov-85 18:45:13 EST Article-I.D.: ut-sally.3576 Posted: Tue Nov 19 18:45:13 1985 Date-Received: Thu, 21-Nov-85 04:13:35 EST Organization: IEEE/P1003 Portable Operating System Environment Committee Lines: 39 Approved: jsq@ut-sally.UUCP Date: Mon, 18 Nov 85 13:28:03 cst From: ihnp4!uiucdcs!ccvaxa!preece@SEISMO.CSS.GOV (Scott Preece) > From: Dan Franklin > Instead of one system call which returns *everything*, there should be > one system call which takes a numeric index "naming" the limit to be > returned. An index of 0 would return the total number of limits. > Limits.h would give the indices. ---------- I'd get rid of the numeric constants part of that, too. Use a call like getenv, supplying a name as an Ascii string. But does this mean we would have to malloc space for anything that was sized to a system limit (i.e., one could no longer say char buf[PATH_MAX] but would have to do: char *buf; long bufsize; ... bufsize = getlimit("PATH_MAX"); if (bufsize >= 0) buf = (char *)malloc(bufsize); else perror("bufalloc:"); at run time? Nobody ever said programming had to be easy, but this could get old pretty quickly... [ If the limits are taken from , presumably a program could, if the programmer so chose, #include that file and size arrays at compile time. -mod ] __ scott preece gould/csd urbana ihnp4!uiucdcs!ccvaxa!preece Volume-Number: Volume 3, Number 28