[OT] Perl woes

[David Cantrell]

On Wed, Jan 28, 2009 at 10:56:41AM -0000, Jonathan Kimmitt wrote:

> Whoever said, the primary purpose of a compiler is to check for
> errors, and only if there are no errors, create the code, was most
> definitely not talking about Perl.

Or about half the XS on the CPAN.  SGI's compilers are picky as hell and
warn about *everything*.  They often spit warnings like "blah blah 64
bit type blah pointer blah blah, assuming you meant ..." and I'd really
like to:

* promote them all to errors instead of warnings;
* then send failing test reports ;-)

Because you can bet that those potential bugs are going unnoticed on the
author's 32-bit Linux box but will really spoil his day when he
eventually moves to a 64-bit machine.  And will spoil it in very
hard-to-debug ways.

> The next time I use == instead of eq to compare two strings, I
> will know to expect it will always
> evaluate to true. What other language does this (apart from C,
> which would invariably return false)

char *string = "hlagh";        /* did I get the * in the right place? */
int true = (string == string);

This is because C doesn't have strings, it has pointers to arrays of
characters, and it's perfectly valid to compare pointers.

> It would be a trivial matter to return an error or warning if ==
> is used for items which aren't numbers

Yes, it is trivial:

$ perl -we "'foo' == 'bar'"
Useless use of numeric eq (==) in void context at -e line 1.
Argument "bar" isn't numeric in numeric eq (==) at -e line 1.
Argument "foo" isn't numeric in numeric eq (==) at -e line 1.

-- 
David Cantrell | Nth greatest programmer in the world

    [OS X] appeals to me as a monk, a user, a compiler-of-apps, a
    sometime coder, and an easily amused primate with a penchant
    for those that are pretty, colorful, and make nice noises.
        -- Dan Birchall, in The Monastery