Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!sundc!citcom!peter From: peter@citcom.UUCP (Peter Klosky) Newsgroups: comp.unix.questions Subject: Re: write (fildes, buf, nbytes) -- is "nbytes" int or unsigned? Message-ID: <40@citcom.UUCP> Date: Fri, 24-Jul-87 15:08:46 EDT Article-I.D.: citcom.40 Posted: Fri Jul 24 15:08:46 1987 Date-Received: Sat, 25-Jul-87 15:04:45 EDT References: <868@bsu-cs.UUCP> Organization: Citcom Systems, Inc., Herndon, VA Lines: 31 Summary: Pedantic comment: two byte int write argument causes bugs. A number of unix applications developed with a disregard for the two-byte integer machines can cause all sorts of bugs, and the syntax of arguments to write sort of scratches the bites. In specific, certain applications will read small files such as keyboard macros or news articles by using stat to find the file size, mallocing space for the file, then reading in the whole thing at once. The problem is when the keyboard macros or news articles grow beyond the limit, the applications sort of get lost and run off the road. As another writer has already pointed out, more thought could have gone into the original design of the write arguments. This type of problem is made worse by technical leaders who do not understand the difference between an int and a long, and in general have a problem with fixing a program that gives no trouble on the existing hardware. In specific, I can recall an incident where a juniour programmer was running lint on a four-byte machine and found an O.S. include file with the type of a time set to an int as opposed to a long. He suggested the type of a time value be changed to a long in the system include file; the technical leader who was responsible for the include files said something like "Why don't you leave me alone so we can cut yet another release of this OS. Just recompile your program and everything will be fine." Whatever the new guy complained about, the technical leader would always tell him to recompile, then everything would be "clean." To make a long story short, the technical leader lasted less than a few months at his position, largely because he had a poor understanding of details. -- Peter Klosky, Citcom Systems (materiel de telecommunications) seismo!vrdxhq!baskin!citcom!peter (703) 689-2800 x 235