From: "Cyrus Patel" Organization: Johannes Gutenberg Universitaet To: djgpp-workers AT delorie DOT com, sandmann AT clio DOT rice DOT edu (Charles Sandmann) Date: Mon, 10 Feb 2003 14:39:14 +0100 MIME-Version: 1.0 Subject: Re: fix for copyrite.c[c]/copyrite.pl Message-ID: <3E47B9E6.29472.C3BDC5DE@localhost> In-reply-to: <10302081737.AA14735@clio.rice.edu> References: <3E450FB4 DOT 28479 DOT B954E177 AT localhost> from "Cyrus Patel" at Feb 08, 2003 02:08:34 PM X-mailer: Pegasus Mail for Windows (v4.02a) Content-type: text/plain; charset=ISO-8859-1 Content-description: Mail message body Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-printable to 8bit by delorie.com id h1ADepT17857 Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On 8 Feb 2003 at 11:37, Charles Sandmann wrote: > I looked at this quickly, and I'm not very happy with it. > > The new version is about 6 times bigger and more complex - much > of the complexity seeming to try to avoid using the glob > command and other portability issues. Walking the dirs manually instead of glob() adds 48 lines - see do_dir() - half of which are white space or brackets. In this case, its a lot more sensible to use a dir walk than glob() because a) this leaves all mem available for full file buffering, and b) as described below, I'm into error checking, and djgpp glob() doesn't support an error handler. In fact, my initial decision for a dir walk was because I assumed I could get the file type from the dirent, and so avoid uneccessary stat()s for directories. That doesn't work on djgpp (djgpp's dirent, like linux's, but unlike bsd/sysv, has no d_type member). So, as you see, what you term as workarounds for compatibility issues, are really workarounds for compatibility issues with djgpp. The complexity has nothing to do with portability: The sixteen #includish lines, and the 21 line workaround for turbo C's getcwd() are well isolated, so even while they might add all of 37 lines to the file, they certainly don't contribute to complexity. In any case, if they bother you, remove them - they neither add nor detract functionality. I wanted to build the executable with turboc and watcomc too because I was under the (mistaken) impression that the DOS path name length limitation (64 chars) could be worked around if stat()/chdir() etc was done for file/directory names sans path (ie, a simple file/dir name relative to the current dir). I then wanted to find out if there were non-dj libs that could get around it, and if so, how. I didn't _really_ care about portability here (beyond that it works under djgpp). If I did, I would not have assumed that a source file would fit in a malloc()d buffer. ;) The added complexity in copyrite.c is really due to ... a) do_file() uses fd io rather than stream io - its more efficient, its easier to check for errors, and its immune to binary/text differences. b) djgpp is in its eighth year. In the 'worst case' scenario, this would mean eight lines of "Copyright (C) 19xx" in a file. This copyright.c coalesces these into one copyright statement (refer to the copyright.c's comments for a description), and must be able to parse these too. c) it does a heck of a lot of error checking. I personally don't like code that doesn't check for errors. Call me old fashioned. :) d) it scans more than just the first line of a file for non-dj copyrights (just as copyrite.pl does), which, as describes in the first 34 lines of the file, is the whole point of the thing. > No documentation (internal or external). Lets see... - libc/src/copyrite.pl has zero comments and zero error checking. - libc/src/copyrite.cc has zero comments and zero error checking. - Copyrite.c (the file I sent) has >75 lines of comments, (or about 12% of the total number of lines), full error checking (12 error messages at the 12 potential points of I/O failure). Are we talking about the same file? :) With respect to the size: Yes, this copyrite.c has 6 times as many lines as the old copyright.cc (which is in turn 25% bigger than copyrite.pl even though it doesn't do half as much as copyrite.pl could). Anyway, does the number of lines really matter? copyrite.c/copyrite.cc/copyrite.pl is a standalone utility for use by DJ and the libc builder(s), and not really intended for general consumption. Notwithstanding the fact that I added comments (because I am not the end user of this tool), I'd be hard pressed to imagine what might be learned from reading the source (other than as an example of how things might be done) copyrite.pl/.cc were quick fixes for an immediate problem, and copyrite.c is simply a fix for the fix - combine the flexibility (read: can be invoked even when perl ain't there) of the .cc with the functionality of the .pl (checking more than just the first line) - coalesce multiple dj-(c) lines into one compound dj-copyright notice per file. This, as well as the functionality that already existed in copyrite.cc/copyrite.pl, is described in detail at the top of copyrite.c. I'm sorry the copy you got didn't have it. :) Regards, Cyrus ps: writing this message has taken me about as long as it took me to write copyrite.c Boy, am I ever verbose. :) --------------------------------------------- Thought for the day: "This we know: All things are connected." -- Chief Seattle, 1849 ü¡