From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu From: "AMSRL-CI-CN" Message-ID: References: <181b9e858518e43368953c1050365780@plan9.bell-labs.com> Subject: Re: [9fans] GUI toolkit for Plan 9 Date: Thu, 28 Feb 2002 14:55:33 +0000 Topicbox-Message-UUID: 5bc22724-eaca-11e9-9e20-41e7f4b1d025 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.