Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!spool.mu.edu!think.com!sdd.hp.com!mips!apple!spies!zorch!xanthian From: xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) Newsgroups: comp.sources.d Subject: Re: v18i084: Zsh 2.00 - A small complaint Message-ID: <1991Apr26.180756.5883@zorch.SF-Bay.ORG> Date: 26 Apr 91 18:07:56 GMT References: <1991Apr25.004233.22900@wolves.uucp> Organization: SF-Bay Public-Access Unix Lines: 67 ggw@wolves.uucp (Gregory G. Woodbury) writes: > I appreciate the effort put into Zsh, but there is one small complaint > that I have. > The package is BSD/SUN specific! > Another tool that I went and poked at only to discover that there are > critical non-portable dependencies not noted in the announcement. A fair complaint, but let me address this from the author's side. I just posted a toy to some of the not archival groups that designs a maze representing a town, after the style of Bard's Tale I's top-level city. I compiled and tested this on both a BSD 4.3 Unix system with cc in old K&R C, and on an AmigaOS 1.3 system with new, ANSI C compliant code, compiled, tested and ran it on both systems with no compile problems, and no visible failures. Only to send it out to the world and find out: 1) I had malloc/free bugs that core dumped on strict allocating systems, but were not caught by systems that malloc using the buddy system and so have lots of free space to trample at the end of a normal allocation. 2) I had file names not unique in the first 8 letters, so MS-DOS systems choked and gagged on the makefile and the unshar. 3) I had misindexed a couple of arrays, which again slipped by on my system (which runs like a Monte Carlo simulation, so errors are not usually visible), but core dumped on systems with strict memeory management. 4) I had a 59 line conditional statement in a do{}while() that blew away small compilers' parse buffer space. 5) Probably lots more. I reemphasize: none of this showed up under substantial testing on two very different systems. Not everyone has access to a wide range of machines, and so you sort of get these possibilities: 1) The author is very sophisticated, and knows that C code portablity is a myth because the OS support is so wildly divergent, and you get a list of "systems this is known to run under", or 2) The author has lots of friends with divergent systems, who share and test code back and forth, and the code reaches the net after a substantial wringing out process occurs behind the scenes, or 3) The author (my case) naively believes that C is C is C, and posts what looks just like usable code, only to find out that what looked like a finished product is only a beta release, and a lot of scrambling around and patch postings follow as the email box swells, and the net makes the code portable as a cooperative effort, or 4) The code doesn't get shared, for fear of criticism. For many of us, with limited facilities, cobbling away without a friend in the world to test our code in private, choices 3 or 4 are all that is available. Kent, the man from xanth.