OpenBSD 4.1: Puffy Strikes Again (O'ReillyNet)

OpenBSD 4.1: Puffy Strikes Again (O'ReillyNet)

Posted May 5, 2007 15:44 UTC (Sat) by tetromino (subscriber, #33846)
In reply to: OpenBSD 4.1: Puffy Strikes Again (O'ReillyNet) by khim
Parent article: OpenBSD 4.1: Puffy Strikes Again (O'ReillyNet)

> "safe mode" - and in both cases it just makes life difficult for programmer but does not actually make the result safer ? In both cases "safe mode" only adds few checks and does not make the result of program more preductable.

Clearly you are not thinking of the same Safe that I am thinking of. The whole point of perl's Safe is to restrict potentially unsafe perl code to a safe subset of the perl API. For instance, if you suspect that a perl script you downloaded might contain a trojan, you can just run it inside Safe to prevent it from accessing your filesystem and network. If it does try to access something it shouldn't, you get an exception, so you can confirm your suspicions. If that's not safety then we are not using the same dictionary.

> If you don't really know what the language construct actually does - it does not matter if there are good or bad things in language syntax: to really understand the program you need to dig deep in source of interpreter and/or scan test suite for sutable test. And even then it's usually just a guess.

I apologize, but what you are describing is called "lack of experience".

> Me ? I've just scanned it few times. But actually I was not the guy who said that Perl is hopeless. There are other guy who did. His name is Larry Wall. Have you heard about him ? It was he who first said that Perl syntax is unmaintable and unfixable mess - it just coincided with my own observations (I was Perl maintainer for local Linux distribution at the time). BTW he quite literally said this - aloud, on conference, so I'm not sure it's easy to find records. But you can easily read narration here (scroll to "What's Wrong with Perl 5").

Have you read the link? Larry Wall made the observations that:
1. perl5 the language lacks a formal written specification, there is only the source code and the test suite. Note that this situation is not unique to perl; ruby is in the exact same boat. This obviously makes it more difficult to make major changes to the perl5 interpreter but is completely orthogonal to whether perl's syntax is a mess or not.
2. perl5's syntax has some awk-like cruft that doesn't belong in a modern general-purpose language (namely, formats).
3. one of the fundamental features of the perl5 syntax - namely, that lists and hashes are prefixed with @ and %, but elements of a list or hash are prefixed with $ - is actually pretty silly; there is no good reason for it. It would make more sense to write @list[5] than $list[5], and that's how it will be done in perl6. However, if this one example makes you think that perl5 is a mess, then we have different definitions of "mess".
4. the way perl5 does tie, overload, and object-orientation is slow and inefficient.

> But if you enable threads support in Perl - everything goes to hell. Threaded Perl breaks things even if you are not using threads and/or C extensions. The mere activation of threads support in Perl broke LaTeX2HTML last time I've checked - and that's pure Perl script, no external C extensions in sight.

That doesn't sound right. For the past 3 years, I've always used perl with threading enabled, and latex2html (20041025 beta version) works fine for me. I've googled, and haven't found anything about latex2html thread problems. Do you have a link? I am interested to know how a pure perl script could possibly be affected by ithreads - to me it sounds impossible...

> Ithreads have separate interpreters for different threads - how it's different from fork+shared memory?

At the kernel level, there is no difference between threads and forked processes with shared memory. However, I am guessing you are trying to say that "ithreads are not very efficient" - which is indeed true. The ithread construct deliberately gives up efficiency for the sake of programmer convenience and backwards compatibility.

> And lack of well-defined semantics is definition of unsafe language!

No. Unsafe semantics are the definition of an unsafe language. For example, C has a formal specification, but its null-terminated strings have had a horrific impact on software security for the past 35 years.

---

(Log in to post comments)