Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-tis!ames!pasteur!ucbvax!unisoft!gethen!bdt!david
From: david@bdt.UUCP (David Beckemeyer)
Newsgroups: comp.sys.atari.st
Subject: Re: Delimma #1 fix or not to fix
Message-ID: <369@bdt.UUCP>
Date: 18 Aug 88 22:22:03 GMT
References: <1116@atari.UUCP> <64086@sun.uucp>
Reply-To: david@bdt.UUCP (David Beckemeyer)
Distribution: comp
Organization: Beckemeyer Development Tools, Oakland, CA
Lines: 28

In article <64086@sun.uucp> cmcmanis@sun.UUCP (Chuck McManis) writes:
 [ He says that developers get into trouble becuase of, among others:
>	- Bugs, code does not work as documented and rather than not use
>	  the broken procedure, the developer uses it the way it currently
>	  works. Not as stupid as above but the better solution is a company
>	  supported work around.

Not use the broken procedure? What if the broken OS function is so fundamental
(say file handling, or console I/O)?  What do you do then?  What's the
alternatetive?  You either hack around the call yourself, stupider than
anything you mentioned (but it's been done), or you live with the broken
function, or you don't write the program for the broken OS.  Oh you could
use the "company supportted work around".  Yea right.   "Oh Malloc doesn't
work?  Yes we know.  Don't use it.   GEMDOS console I/O doesn't work either,
but you're not allowed to use the BIOS if you want your program to
work with I/O redirection.  No you can't have a larger than 16MB disk
partition.    40-folder bug?  Umm.. well...  Have a nice day."

Anyway I think the funniest thing about this whole discussion is that
if the Malloc bug were the worst of the problems with the ST and Atari
we'd all be in great shape!



-- 
David Beckemeyer (david@bdt.uucp)	| "Don't call me Stupid!"
Beckemeyer Development Tools		| "No.  That would be an insult
478 Santa Clara Ave, Oakland, CA 94610	|  to all the stupid people!"
UUCP: {unisoft,sun}!hoptoad!bdt!david 	|         - A fish called Wanda