[OT] Perl woes
david at cantrell.org.uk
Wed Jan 28 14:25:38 GMT 2009
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
* 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
> 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
More information about the london.pm