Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!sun!pitstop!sundc!seismo!uunet!mcvax!kth!draken!tut!santra!kampi!hsu From: hsu@kampi.hut.fi (Heikki Suonsivu) Newsgroups: comp.sources.d Subject: Re: v18i002: Fido/Usenet gateway, Part01/05 Message-ID: <20314@santra.UUCP> Date: 9 Mar 89 21:22:30 GMT References: <1534@papaya.bbn.com> <3082@ddsw1.MCS.COM> Sender: news@santra.UUCP Reply-To: hsu@kampi.UUCP (Heikki Suonsivu) Organization: Helsinki University of Technology, Finland Lines: 66 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