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) {
[download]

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);
[download]

Well, the whole design seemed convoluted for what looked to me to be pretty simple functionality.

        - tye (but my friends call me "Tye")

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.