Oh my god, you killed Perl! You bastards!

Sorry, couldn’t resist the title. I’ve finally gotten around over the last couple of days to taking a close look at [Perl6](http://dev.perl.org/perl6/). I’m scared. I’ve been excited about the idea of Perl6 since the first rumblings started. A compiler that will compile to bytecode and accept a backed to create native executables? What’s not to love? But somehow, I thought all the things I loved about Perl–the things I consider the essentials of the language–would remain untouched. What are those? Well, as a matter of philosophy, I’ve always loved Perl for its status as a glorified scripting language, a way to make all of the bash, csh, and tcsh scripts i’ve written for various environments over the years portable. I also like the way it has always positioned itself as, first and foremost, a text-processing language, and that it has never let syntax or “propriety” get in the way of letting people write code. Specifics? Okay, the big ones:

* Weak typing.
* Autovification.
* The fact that function and subroutine overloading is so difficult as to be impractical.
* The lack of UnreadableCAMLCase and useless.dots.for.things.that.aren’t.hierarchical (or is that hierarchical.aren’t.that.things.for.dots.useless?)
* The ability to ignore objects entirely.

Perl6, however seems to be intent on taking the worst features of Python, Ruby and C#. I couldn’t believe my eyes when I started looking around and found gems like: ‘[-> becomes ., like the rest of the world uses](http://dev.perl.org/perl6/doc/design/syn/S03.html)’ and ‘%people .{‘john’} = Person .new;’. Better still, the top reasons that the perl6 designers think people might want to convert code to Perl6:

* explicit strong typing
* proper parameter lists
* active metadata on values, variables, subroutines, and types
* declarative classes with strong encapsulation

Followed closely by:

* subroutine overloading
* user-definable operators (from the full Unicode set)

These are powerful features, of course, but they’re also the reasons that maintaining C programs is a full time job. I’m not thrilled about macros either, but at least they’re written in Perl, not C’s limited preprocessor directives. For my money, these are all acceptable tradeoffs for named regexes and incremental matches against streams. As long as I can circumvent the typing and OO class declarations that is. And it looks like I can. I’m sure I’ll get used to it eventually, but at first glance, it looks like the Perl6 crew is openly embracing exactly the features of Python and Ruby that have kept me away from those languages, and that’s disappointing. i thought the code snippets i’d seen floating around looked strange.

Big News for OpenBSD

Theo de Raadt publically announced yesterday that the 3.8 release will make possibly the biggest change in the changelog to date: they’re recongfiguring malloc(3):

> This release will bring a lot of new ideas from us. One of them in particular is somewhat risky. I think it is time to talk about that one, and let people know what is ahead on our road.
>
> Traditionally, Unix malloc(3) has always just “extended the brk”, which means extending the traditional Unix process data segment to allocate more memory. malloc(3) would simply extend the data segment, and then calve off little pieces to requesting callers as needed. It also remembered which pieces were which, so that free(3) could do it’s job.
>
> The way this was always done in Unix has had a number of consequences, some of which we wanted to get rid of. In particular, malloc & free have not been able to provide strong protection against overflows or other corruption.
>
> Our malloc implementation is a lot more resistant (than Linux) to “heap overflows in the malloc arena”, but we wanted to improve things even more.
>
>Starting a few months ago, the following changes were made:
>
> – We made the mmap(2) system call return random memory addresses. As well the kernel ensures that two objects are not mapped next to each other; in effect, this creates unallocated memory which we call a “guard page”.
>
> – We have changed malloc(3) to use mmap(2) instead of extending the data segment via brk()
>
> – We also changed free(3) to return memory to the kernel, un-allocating them out of the process.
>
> – As before, objects smaller than a page are allocated within shared pages that malloc(3) maintains. But their allocation is now somewhat randomized as well.
>
> – A number of other similar changes which are too dangerous for normal software or cause too much of a slowdown are available as malloc options as described in the manual page. These are very powerful for debugging buggy applications.

Sounds good, and hopefully others will follow OpenBSD’s lead here. The new malloc configuration will make exploitable buffer overflows almost a thing of the past.

Here’s the catch, though, if your code has an overflow or overread, even one that’s not particularly dangerous, it will break under 3.8:

> – When you free an object that is >= 1 page in size, it is actually returned to the system. Attempting to read or write to it after you free is no longer acceptable. That memory is unmapped. You get a SIGSEGV.
>
> – For a decade and a bit, we have been fixing software for buffer overflows. Now we are finding a lot of software that reads before the start of the buffer, or reads too far off the end of the buffer. You get a SIGSEGV.

This has the potential to cause growing pains for a lot of people. If all goes according to plan, though, everyone wins with this setup. OpenBSD itself is stronger, and programmers will be forced to rewrite offending code in ways that make it more stable and secure for everyone. For most big projects, the openBSD porters are undoubtedly already submitting patches back to the main development trees.

Plus c’est la même chose

Two months ago, when I last updated this space, I expected to be back in a day or so. Little did I know. Somehow, posting for [The Digital Photography Weblog](http://digitalphotography.weblogsinc.com) and [The Unofficial Apple Weblog](http://www.tuaw.com) Has taken a great deal more time and energy than I could have guessed. Prolonged computer troubles didn’t help much either. I haven’t given up, though, and we’ll see how things go now that I’m starting to get settled into both the freelancing gig and my new iBook.