Path: utzoo!attcan!uunet!lll-winken!ames!ucsd!rutgers!aramis.rutgers.edu!athos.rutgers.edu!webber From: webber@athos.rutgers.edu (Bob Webber) Newsgroups: comp.sources.d Subject: Comments on INSERT.c (was: Re: It is better to remain silent...) Message-ID: Date: 8 Jan 89 23:49:00 GMT References: <308@twwells.uucp> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 92 To: uunet!proxftl!twwells!bill@rutgers.edu novavax!twwells!bill@rutgers.edu webber In article <308@twwells.uucp>, bill@twwells.uucp (T. William Wells) writes: > It is better to remain silent and be thought a fool than to speak and > remove all doubt. But fortunately you spoke. It takes a brave man to make a fool of themself like this just to learn a bit more about unix. The net takes its hat off to you Bill. Now, let's take a look at the program: > First, let's notice that this is essentially equivalent the cp > command, minus cp's frills. It does do one thing that I don't believe > all cp's do: it verifies that the copy succeeded. But one can do the > job with a little shell script that does a cp, some ls's, and some > tests. Thus this program is an example of bad analysis: it is a new > program to do what existing tools can already do. No, it is fundamentally different from cp. cp truncates to 0 an existing file (or unlinks it) before writing into it (or creating a new one). INSERT writes into the file and then truncates it to the appropriate size. This difference is crucial if you are on a multiuser system that is out of file space. > Second, it is nonportable. It is Berkeleyoid specific code. > Ftruncate marks it as such. There are also those UNIX-specific I/O > calls. It is as portable as possible. Tell me how to accomplish the same correctly on a POSIX/v7 system and I will be happy to make the program more portable. [By the way, a request for such an equiv has been posted to comp.unix.wizards, so people interested in this coding aspect should watch for conversation on it in that group (assuming that there is anything to say other than it just can't be done except in BSD).] > Third, it is a bad program, even if we didn't care about portability. > > 1) The glorified numeric error codes. I mean really! Each error > message is just "Error so-and-so : read the source..."! Each > error message should have said something useful, dammit! That has been improved in the new release (Jan688 release of INSERT in alt.sources). However, since perror was used to print the original messages, they were pretty useful to begin with. Incidently, the new release adopts the convention that if only one file name is given, then standard input is read for what to insert (a sufficiently useful enhancement to merit a the new release). > 2) The lack of variable naming consistency. If we're going to > have the verbosity of words-for-names and capitalization of > each word, names like `fdin', `fdout', and `chs' don't belong. > (This one is arguable.) Consider it argued. fdin, fdout, and ch are sufficiently standard in unix programming that they are almost predeclared. chs for multiple ch's is just a bit of humor. The rest of the names are equally descriptive, although they are longer, e.g., ReadExit and ReadSize (perhaps ReadTotal would be even better, but I will hold off a release for that until some more useful can be bundled with it). > 3) The unnecessary code sequences. The lseek's and the ftruncate > serve no purpose that I can see. The lseeks position the file at the beginning. Oddly enough, the man page on open doesn't assert that this is default on our system. From a diagnostic point of view, the lseeks let one know what the state of the file is before the first read, which could be interesting. The ftruncate is crucial, otherwise when writing a smaller file into a bigger one, the size doesn't change as it should. > 4) The use of a cast to create a long constant. This indicates > ignorance of C, or a slavish obedience to a not-understood > coding standard. Aren't you worried about portability to systems with 16 bit ints running BSD? The man page clearly says that arg is a long and lint expects it. > 5) Probably others, but I'm too blind mad to read it again. I guess it was a rather long piece of code for you to have to read all the way thru. > We'll further note that writing a structured program and using a > consistent style (except for the naming and one minor glitch) did not > prevent him from writing a bad program. That remains to be demonstrated. > And this !@#$%^&* guy teaches!!!!! ????? But some refuse to learn. ---- BOB (webber@athos.rutgers.edu ; rutgers!athos.rutgers.edu!webber)