Mail Archives: djgpp-workers/2003/02/10/08:40:53
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 -