Path: utzoo!attcan!uunet!husc6!bloom-beacon!mit-eddie!ll-xn!ames!pasteur!agate!garnet.berkeley.edu!ked From: ked@garnet.berkeley.edu (Earl H. Kinmonth) Newsgroups: comp.lang.c Subject: Re: turboc/msc spawn* Message-ID: <11051@agate.BERKELEY.EDU> Date: 17 Jun 88 15:52:38 GMT References: <2286@ucdavis.ucdavis.edu> <6685@sigi.Colorado.EDU> Sender: usenet@agate.BERKELEY.EDU Organization: University of California, Berkeley Lines: 45 In article <6685@sigi.Colorado.EDU> swarbric@tramp.Colorado.EDU (Frank Swarbrick) writes: >I have a better question... How does one go about reporting bugs to software >companies? I have found four or five bugs in Turbo C 1.5, and I would like to >tell them, but if I send them a letter telling them of them will they actually >listen? You can write Borland. I did once, and they even replied --- six weeks later. However, when I say "replied," I mean that I got mail back from them, not answers to the questions I had raised (primarily mistakes in the documentation claims about routines being the same as in UNIX). They also promised a coupon for $15 worth of time on CompuServe. It was to come under separate cover. A year later, I am still waiting. -:) On a related note -- I find it interesting that computer magazines such as PC Journal, Byte, etc. have made no mention of bugs in QC or TC in any of the reviews I've seen. Perhaps this has to do with using only benchmark programs that do nothing to test the system calls. Or perhaps it has to do with the advertising pages these companies buy. The ability to compile and rapidly execute contrived benchmarks has nothing to do with real programming. I'd happily settle for slower execution if that went with greater freedom from bugs. Two or three seconds saved in execution cannot repay me for two or three days spent programming around bugs or testing badly documented routines to find out how they really work. It seems to me that there ought to be a benchmark based on some large, complex program that really talks to the operating system and video io. The performance criteria would then be the number of patches needed for any one compiler and the number of person hours (months) required to recompile the benchmark and get it to execute successfully. E H. Kinmonth Hist. Dept. Univ. of Ca., Davis Davis, Ca. 95616 916-752-1636/0776 Disclaimer: This is AmeriKa! Who needs a disclaimer! Internet: ehkinmonth@ucdavis.edu cck@deneb.ucdavis.edu BITNET: ehkinmonth@ucdavis UUCP: {ucbvax, lll-crg}!ucdavis!ehkinmonth {ucbvax, lll-crg}!ucdavis!deneb!cck