[aklug] Re: perl lists question, sorting, sort of.

From: Arthur Corliss <acorliss@nevaeh-linux.org>
Date: Wed Aug 18 2010 - 01:25:30 AKDT

On Wed, 18 Aug 2010, Michael Fowler wrote:

> That is the Perl equivalent of an in_addr struct (in_addr_t is just a
> typedef, and not the struct that inet_aton and inet_ntoa use).
>
> Basically, the Perl socket functions are very thin wrappers around the C
> functions. They receive an SV (scalar value) containing a string, they
> pull out the (char *) pointer, and cast it to a (struct in_addr *).

Thanks for the clarification.

> Making your intent clear protects you from maintenance headaches.
> Adding code to make it more "secure", when it in fact does nothing,
> makes it less secure, because it's harder to understand and maintain.
>
> Protecting against external data sources is vital. That is not the same
> thing as future-proofing your code to protect against changes to the
> code. That kind of "security" leads to over-design, and vestigial
> pieces that confuse any subsequent work.
>
> To be clear, /s changes the meaning of the . metacharacter; it will
> match a newline. /m changes the meaning of ^ and $ to match after and
> before a newline, respectively. You are not using ., ^, or $ in your
> regex.

Consistency is a big part of secure programming, Mike. And these flags
merely enforce the concept that most of us are line-oriented and
subconciously expect our regexes to work the same way. Now, you can differ
all you want with PBP and Conway. I maintain a custom .perlcriticrc and
.perltidyrc just to account for those differences. But at the same time
I've found that reliability and maintainability is increased when I have
minimal guarantees of consistency and conventions.

Assuming you've customized your source validation tools to abide by rules
you can rationally agree with I have yet to see an instance where this has
ever compromised readability, maintainability, or any other bugaboo you'd
care to throw out there. Of course, none of this alleviates the need for
a good and comprehensive test suite.

Now, if you'd like to share an anecdote of an instance where you found the
opposite, please share. But it needs to be more than "unmaintainable
because it utilized a convention I disliked".

         --Arthur Corliss
           Live Free or Die
---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Wed Aug 18 01:25:38 2010

This archive was generated by hypermail 2.1.8 : Wed Aug 18 2010 - 01:25:38 AKDT