Well, some of this is more emotional than logical, but I've
been half wanting to vent about ePerl for a while. I never
would have seen ePerl except I was trying to see if
FilterProxy could accomodate my simple browser customizations
like dropping certain ads, adding "softwrap" to PM text
boxes, stipping most but not all scripting, flagging
interesting bits, etc.
Okay, the first problem was that I was only looking at the
source code because I couldn't get it to compile under
Windows NT and the first thing I notice is lots of big
claims about how incredibly portable the code is ("ePerl
was written with portability in mind."). But my
annoyance at that really started to climb as I kept seeing
tons of C code that should have been much smaller, much more
portable Perl code. In the end, I read a whole lot of C
code and didn't find anything that wouldn't have been
better done in Perl. There might be some in there, but I
didn't find it.
Now this may not be a great reason to avoid using ePerl
except that this will stop you from moving your code to a
non-vanilla-Unix platform and there are plenty of alternatives
to ePerl available.
At first, making their code portable was pretty easy. I just
had to #ifdef out bits that didn't apply under Windows NT
and fix some small bits of stupid, unportable code
by replacing it with smaller, less stupid, more portable
code that worked better than the original, even under Unix.
But eventually I realized that their lack of understanding
of portable programming had permeated their code too deeply
for me to be able to quickly patch it back into sanity and
I gave up. I realized that I could probably write a tiny
Perl-only replacement for ePerl faster than I could fix
their C code (though I didn't plan to support whatever they
were doing to support some CGI security features that I
didn't even glance at since they were of no use to me).
Okay, much of the code was not as ugly as lots of code I've
seen. As I said, this is an emotional rant. I hope the
authors of ePerl never see it, by the way.
So what are some of the things they did wrong?
My favorite is:
fseek(fp, 0, SEEK_END);
nBuf = ftell(fp);
[...]
if ((cpBuf = (char *)malloc(sizeof(char) * nBuf+1)) == NULL) {
ePerl_SetError("Cannot allocate %d bytes of memory", nBuf)
+;
CU(NULL);
}
fseek(fp, 0, SEEK_SET);
if (fread(cpBuf, nBuf, 1, fp) == 0) {
So, they seek to the end of a file without even bothering
to test whether the fseek() failed. Then they use ftell()
to get the size of the file (and again don't check for
failure). Okay, this won't work in tons of situations.
But even if you didn't care about those situations, why
not just use fstat() to get the file size?? Then the way
they've done fread() will fail if less than nBuf bytes are
available. fread(cpBuf,1,nBuf,fp) would have been better.
Then there are little things like:
fprintf(fp, "%c", c);
Well, the whole design seemed convoluted for what looked to
me to be pretty simple functionality.
-
tye
(but my friends call me "Tye") |