karl@ddsw1.MCS.COM (Karl Denninger) (03/08/89)
In article <1534@papaya.bbn.com> rsalz@uunet.uu.net (Rich Salz) writes: >Submitted-by: Heikki Suonsivu <hsu@santra.hut.fi> >Posting-number: Volume 18, Issue 1 >Archive-name: fnet/part01 This comment applies to all 5 parts, of course. First, the Makefile distributed had SPACES instead of TABS separating the rules. Needless to say, that didn't work. A quick substitution in vi fixed that problem. The more serious problems in the package as distributed are: o You must guess what "SEEK_END" and "SEEK_SET" are (not too horrid); they're not defined ANYWHERE but are used! This is just plain sloppy coding. o There are several "automatic" definitions in the ".h" files that don't work right, and cause the build to bomb. Those have been taken care of. o You must have the PD "ndir" sources online, and you must change several lines of code to accomodate them; the author apparently has a different implementation than the one that has been posted to the Usenet. o The Makefile has "LNFLAGS" defined where it is obviously supposed to be "LDFLAGS"; again, not a major problem, but horridly sloppy! o (this is the killer) You must have an "alloca" function! 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. I'm concerned that this package got into "comp.sources.unix" without even so much as a "make". It doesn't even come close to building as distributed, and with the "alloca" requirement, it will never work on a majority of System V environments. This code is NEITHER System V nor 4BSD at the moment, and will require MAJOR work before it's usable by Usenet sites. "Alpha" release doesn't even describe it in it's present state. Alt.sources would have been a much more appropriate place to post this. -- Karl Denninger (karl@ddsw1.MCS.COM, ddsw1!karl) Data: [+1 312 566-8912], Voice: [+1 312 566-8910] Macro Computer Solutions, Inc. "Quality solutions at a fair price"
hsu@kampi.hut.fi (Heikki Suonsivu) (03/10/89)
In article <3082@ddsw1.MCS.COM> karl@ddsw1.UUCP (Karl Denninger) writes: >First, the Makefile distributed had SPACES instead of TABS separating the Apparently shar I used did that, original files have tabs there. > o You must guess what "SEEK_END" and "SEEK_SET" are (not too SEEK_END and SEEK_SET are defined in unistd.h (comes with SVR3) ? > o You must have the PD "ndir" sources online, and you must change Again, SVR3. > has a different implementation than the one that has been posted One floating around as posix-compatible directory routines seems to be same as SVR3 stuff. Posix I guess? Ndir replaces it quite easily I think, #define dirent direct. > o The Makefile has "LNFLAGS" defined where it is obviously supposed No, its flags for lint. > o (this is the killer) You must have an "alloca" function! #define alloca malloc is a quick hack around it. It shouldn't use up too much memory. >"alloca" is not a System V function. Yes, there are hacks out there for True, most systems I have used have it but its often broken. >I'm concerned that this package got into "comp.sources.unix" without even >so much as a "make". It doesn't even come close to building as distributed, I compiled that version on both Motorola 8400 and Microport 386 before posting it, though didn't read lint output carefully, there is one strchr with bad args. But it certainly was make'd and exactly posted code had been running in two systems for few weeks. Current version lints cleaner, but I won't toss it out until I have tested it a while. >This code is NEITHER System V nor 4BSD at the moment, and will require MAJOR SVR3. Minor work to 32 bit svr* if one has ndir/posix-dir (I'm surprised if there are lots of people without either?) >work before it's usable by Usenet sites. "Alpha" release doesn't even Loaded it to CT miniframe (SVR1+some SVR2) few weeks ago, took about 30 minutes to get it up. I #defined alloca malloc and then compiled posix-dir routines. It was just waiting for compilation. 286 would need more work because of nodelist index routines which in practice expect 32bits. That is to my opinion bigger problem for xenix? Sure its not BSD, but testing would be difficult for me. True, its trash and quick hacks, which its mentioned often in messy doc files coming with it. Maybe alt.sources could have been better (and faster). When I asked if anyone is interested about it I certainly mentioned its limitations, should have sticked that message to posting. To make it better, please send diffs to: - hsu@fingate.BITNET ..!mcvax!santra!hsu Heikki Suonsivu @ 2:504/1 2:504/7 hsu@santra.hut.fi hsu@kampi.hut.fi Kuutamokatu 5 A 7/02210 Espoo/FINLAND voice +358-0-171377 fax -628948 v22bis -171558 . not found
blume@netmbx.UUCP (Heiko Blume) (03/16/89)
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 ? {btw: i looked in the bsd manuals, alloca is both system and compiler dependant - use is discouraged ! not nice to use it in software that should be portable} -- Heiko Blume,Seekorso 29,D-1000 Berlin 22,VOICE=(+49 30)365 55 71,BBS=()365 75 01 TELEX=183003 intro d,FAX=()882 50 65|ARPA =crash!pnet01!pro-cess!blume@nosc.mil PSI =PSI%45300043109::netmbx:blume |BITNET=pro-cess.UUCP!blume@PSUVAX1 UUCP =blume@netmbx.UUCP |INET =blume@pro-cess.cts.com
karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) (03/17/89)
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.
Have you looked in /lib/libPW.a?
--Karlkarl@ddsw1.MCS.COM (Karl Denninger) (03/19/89)
In article <KARL.89Mar17104655@triceratops.cis.ohio-state.edu> karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) writes: >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. > >Have you looked in /lib/libPW.a? In the '386 Xenix libraries? ar: /lib/386/SlibPW.a does not exist Now, if I try to scan all the libraries (which I did) I don't find an "alloca" either.... and the last 4BSD manuals I looked at said something to the effect of "this call is both implementation and MACHINE dependant". It's a bad idea to use those kinds of calls in a portable package, as it makes the package non-portable. Does _anyone_ have it working under Xenix? If so I'd like to hear from you! --- Karl Denninger (karl@ddsw1.MCS.COM, ddsw1!karl) Data: [+1 312 566-8912], Voice: [+1 312 566-8910] Macro Computer Solutions, Inc. "Quality solutions at a fair price"
blume@netmbx.UUCP (Heiko Blume) (03/22/89)
In article <KARL.89Mar17104655@triceratops.cis.ohio-state.edu> karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) writes: /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. / /Have you looked in /lib/libPW.a? alloca is definitely not available in sys v but i got a mail today that a friend of mine has ported GNU emacs to xenix, so there sure is some way to emulate / substitute that since emacs uses alloca. however there is this alloca.c but i dont know if it works. i'll investigate how the port was done and post some hints (hopefully). -- Heiko Blume,Seekorso 29,D-1000 Berlin 22,VOICE=(+49 30)365 55 71,BBS=()365 75 01 TELEX=183003 intro d,FAX=()882 50 65|ARPA =crash!pnet01!pro-cess!blume@nosc.mil PSI =PSI%45300043109::netmbx:blume |BITNET=pro-cess.UUCP!blume@PSUVAX1 UUCP =blume@netmbx.UUCP |INET =blume@pro-cess.cts.com
allbery@ncoast.ORG (Brandon S. Allbery) (03/24/89)
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@<backbone> NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser
guy@auspex.UUCP (Guy Harris) (03/25/89)
>/Have you looked in /lib/libPW.a? > >alloca is definitely not available in sys v The source to an "alloca" implementation for the WE32K chip definitely *is* available on the System V Release 3.0 source tape. I assume an assembled version of that code is available in the "libPW" library in the System V Release 3.0 binary distribution for the 3B2. I can't speak for other S5R3 releases (e.g., the 80386 version, or any ports of it to other architectures, but "alloca" has been in S5 (and S3, and... and PWB/UNIX 1.0) since time immemorial.