From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <65cb447dbaf5f9da39d670e4f0596c79@plan9.bell-labs.com> From: presotto@plan9.bell-labs.com To: 9fans@cse.psu.edu Subject: Re: [9fans] GUI toolkit for Plan 9 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-uumxxwinqahqgmfnqlwxyxymmp" Date: Thu, 28 Feb 2002 10:22:23 -0500 Topicbox-Message-UUID: 5bd3fca6-eaca-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-uumxxwinqahqgmfnqlwxyxymmp Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I think 3B2 code deserves its own place in hell. Poring over the ESS#5 code, someone found that there were lots of strcmp(p, "f(") == 0 checks (I may have gotten the exact string wrong but it's close). It took us a while to figure out why. Apparently, location 0 on the 3b had the 3 bytes 'f' '(' '\0', someone noticed that when programs blew up they were pointing to "f(", and the worlds most amazing kludge for detecting nil pointers was born. I'm beginning to be convinced that, with the exception of Ken's registerization, bugs in optimizing compilers are more likely mistakes than knowing attempts to hang over the edge too far. I heard a rumor yesterday that I'ld like dispelled if possible. It was that the Linux kernel had to be compiled with optimization turned on to work. I just tried compiling my Redhat system without and it crashed but then I turned optimization on and it still didn't work, so clearly I'm incompetent. --upas-uumxxwinqahqgmfnqlwxyxymmp Content-Type: message/rfc822 Content-Disposition: inline Received: from plan9.cs.bell-labs.com ([135.104.9.2]) by plan9; Thu Feb 28 10:04:19 EST 2002 Received: from mail.cse.psu.edu ([130.203.4.6]) by plan9; Thu Feb 28 10:04:18 EST 2002 Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.20.6]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 1A7B8199B9; Thu, 28 Feb 2002 10:04:11 -0500 (EST) Delivered-To: 9fans@cse.psu.edu Received: from mercury.bath.ac.uk (mercury.bath.ac.uk [138.38.32.81]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 3E22A1998C for <9fans@cse.psu.edu>; Thu, 28 Feb 2002 10:03:07 -0500 (EST) Received: from news by mercury.bath.ac.uk with local (Exim 3.12 #1) id 16gRyI-0006Ly-00 for 9fans@cse.psu.edu; Thu, 28 Feb 2002 14:55:50 +0000 Received: from GATEWAY by bath.ac.uk with netnews for 9fans@cse.psu.edu (9fans@cse.psu.edu) To: 9fans@cse.psu.edu From: "AMSRL-CI-CN" Message-ID: Organization: US Army Research Laboratory References: <181b9e858518e43368953c1050365780@plan9.bell-labs.com> Subject: Re: [9fans] GUI toolkit for Plan 9 Sender: 9fans-admin@cse.psu.edu Errors-To: 9fans-admin@cse.psu.edu X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.0.8 Precedence: bulk Reply-To: 9fans@cse.psu.edu List-Help: List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Archive: Date: Thu, 28 Feb 2002 14:55:33 GMT wrote in message news:181b9e858518e43368953c1050365780@plan9.bell-labs.com... > what works and what doesn't. Moving from the VAX to the > 68020 uncovered lots of null references that were going > unnoticed in the past. Long ago, I went through all the user-mode UNIX System V source code and identified and fixed as many of these kinds of bugs as I could find. Unfortunately the system for trouble reporting was utterly not up to the task of feeding these back to the official developers. I think finally most of them got fixed indirectly via Sun picking them up when Guy Harris helped merge the System V and BSD sources for them, since he had my fixed-up System V sources to work from. Anyway, in the process of doing that work, also in dealing with some of the code from the AT&T UNIX System ToolChest, I found that a lot of these VAXisms appeared to have turned up when AT&T moved the code to 3B2s (WE32000 architecture), but instead of changing the code to be truly portable, workarounds were installed under control of #ifdef u3b conditionals. Maybe that resulted from some policy of having to overdocument every change to the base code unless it was made processor-specific; I don't know. The biggest culprits seemed to be passing 0 to terminate execl argument lists and dereferencing argv[i] before testing for i==argc. --upas-uumxxwinqahqgmfnqlwxyxymmp--