Path: utzoo!attcan!uunet!lll-winken!ames!mailrus!uflorida!novavax!twwells!bill From: bill@twwells.uucp (T. William Wells) Newsgroups: comp.sources.d Subject: Re: Comments on INSERT.c Message-ID: <343@twwells.uucp> Date: 18 Jan 89 21:02:47 GMT References: <308@twwells.uucp> <13336@ncoast.UUCP> Reply-To: bill@twwells.UUCP (T. William Wells) Organization: None, Ft. Lauderdale Lines: 153 Summary: Expires: Sender: Followup-To: Distribution: Keywords: In article <13336@ncoast.UUCP> allbery@ncoast.UUCP (Brandon S. Allbery) writes: : As quoted from by webber@athos.rutgers.edu (Bob Webber): : +--------------- : | In article <308@twwells.uucp>, bill@twwells.uucp (T. William Wells) writes: : | > 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).] : +--------------- : : Xenix 5.3.1, at least, has chsize(); this amounts to the same thing. V7 : and System V.2 have no such functionality. I don't know about Posix. : : Bill: ftruncate() being the whole point of the program, referring to it as : a non-portable cp sounds like a missed target to me. Well, I did miss the point of the program. And, as has already been hashed out, using ftruncate or some other nonportability somewhere in the program is pretty much forced, since truncating a file is nonportable. However, my portability complaint has more to it than that. See below. : +--------------- : | > Third, it is a bad program, even if we didn't care about portability. : | > : | > 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). : +--------------- : : I have yet to be flamed for calling a random counter variable "cnt", a : random stat buffer "sb", a random file descriptor or file pointer "fd" or : "fp" (respectively), a random char pointer "cp", etc. This is a foolish : attack, given that you haven't flamed anyone *else* who uses the convention. The point of the complaint was not the names. Me, I'd use simple names and be done with it. Consistency is one of the highest virtues when it comes to style; the complaint was that this code used two different styles for naming. : +--------------- : | > 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 : +--------------- : : UNIX seems to assure it; but for portability, you hit the mark. I've *used* : OSes where the file pointer was undefined after an open(). [I prefer not to : think about them...!] Unfortunately, the use of the low-level calls -- : including ftruncate() pretty much invalidates the portability. Nice try, : though. [Actually, enough C libraries implement open(), read(), write(), : etc. on non-UNIX systems that they can be considered at least somewhat : portable.] Y'all have missed the point about portability. There are four nonportable things in the program: 1) The include files 2) Ftruncate 3) The Unix-style I/O calls 4) The int/long identity assumption We can look at three levels of portability: 1) Portability within Berkeley-like systems. The code is Berkeley specific. It had all four of the above sins, only the last of which has been fixed; thus the code can't be expected to port cleanly to non-Berkeley systems. 2) Portability within Unix-like systems. Two things would make it better for porting to non-Berkeley Unix-like systems: Put the ftruncate call in a macro, and put the macro at the top of the program, so that people who are porting the program can see what is going on. For systems which do have some way of doing a file truncate, the change is then simple and obvious. Remove all the include files except stdio.h. They are there to get ONE constant that would be better obtained from stdio.h (BUFSIZ is the replacement I have in mind). At this or the previous level of portability the lseek's are not required. 3) Portability in general. Presuming that one has fixed the above problems, there still remains the Unix-style file I/O. While it is true that many systems provide a similar interface, not all do. Thus, for this level of portability, one must replace those calls with standard I/O calls. For example, Microsoft C for MS-DOS has all the Unix-style I/O calls but the second parameter to open() is different! MS-DOS does have a way to truncate files, so this is not moot. (For those who are curious, one truncates a file by seeking to the desired position to truncate and writing zero bytes. One probably has to do the latter as an explicit DOS call, since, presuming that the write() call isn't brain damaged, it filters out zero byte writes.) Note also that, if the code were written for this level of portability, the lseek's would still be unnecessary. : +--------------- : | > 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. : +--------------- : : It also raises a *true* point: the use of structure and consistent style : didn't make the program's *purpose* clear to at least one net.reader. Which : is why "self-documenting" languages and programming styles have always : failed. Damn right. And they always will. "How" is not "why". Oh yeah, I've found another use for the program. Suppose you have a file specially laid out on your file system and you want to update the file. If you just do a cp, the file gets truncated and then new blocks are allocated, probably at random. Using this program would eliminate that by directly re-using the blocks. This is useful, even on a single-thread system. Like MS-DOS. (Yuck!) "How" is not "why"! --- Bill { uunet!proxftl | novavax } !twwells!bill