delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2003/02/10/08:40:53

From: "Cyrus Patel" <cyp AT fb14 DOT uni-mainz DOT de>
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)
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

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


- Raw text -


  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019