Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!ames!ncar!tank!shamash!nic.MR.NET!hal!ncoast!allbery From: allbery@ncoast.ORG (Brandon S. Allbery) Newsgroups: comp.sources.d Subject: Re: v18i002: Fido/Usenet gateway, Part01/05 Message-ID: <13493@ncoast.ORG> Date: 23 Mar 89 23:50:08 GMT References: <1534@papaya.bbn.com> <3082@ddsw1.MCS.COM> <2380@netmbx.UUCP> Reply-To: allbery@ncoast.UUCP (Brandon S. Allbery) Followup-To: comp.sources.d Organization: Cleveland Public Access UN*X, Cleveland, Oh Lines: 36 As quoted from <2380@netmbx.UUCP> by blume@netmbx.UUCP (Heiko Blume): +--------------- | In article <3082@ddsw1.MCS.COM> karl@ddsw1.UUCP (Karl Denninger) writes: | >The last requirement blows the package out of the System V arena entirely; | >"alloca" is not a System V function. Yes, there are hacks out there for | >some systems, but not all. Xenix is one of the "not all" ones. | | very interesting ! does this tell me that the alloca.c distributed with | GNU emacs just can't work on xenix ? has anyone ported GNU emacs yet ? +--------------- System V (possibly including SCO Xenix) has alloca() in -lPW (PWB compatibility library); but my experience is that it doesn't work well enough for use by GNU programs. The alloca.c that comes with GNU Emacs is a "fake" alloca -- it doesn't work the way the real alloca() does, instead it uses regular malloc()'ed storage and a table of pointers to who allocated it; if the allocating function has returned since the last call to alloca(), the space is free()'d. This works for the most part, although there are certain pathological cases (consider a program which only allocates storage with alloca() in a single function which is always called at the same level in the program: alloca()'d storage will simply grow to infinity). A workaround involves calling alloca(0) at the uppermost level every so often to free all lower-level storage. GNU Emacs calls alloca(0) in its main loop, so it doesn't grow to infinity. 386 Xenix can have a real alloca() written for it; it just doesn't have a working one. 286 Xenix has the 64K stack frame problem, which is part of why GNU Emacs won't compile on 286es.... ++Brandon -- Brandon S. Allbery, moderator of comp.sources.misc allbery@ncoast.org uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu Send comp.sources.misc submissions to comp-sources-misc@ NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser