Re: [pcre-dev] [Bug 1295] add 32-bit library

On Sun, 28 Oct 2012, Tom Bishop, Wenlin Institute wrote:

> A naive PCRE user only wants to know whether a file begins with a
> particular character sequence, for example, "#!/bin/bash". Not caring
> whether the file is valid UTF-32 and not having read the documentation
> very carefully, this programmer uses the flag PCRE_NO_UTF32_CHECK so
> that the program will run faster (or maybe just having copy-pasted it
> from somewhere). PCRE says the file matches "#!/bin/bash", so the
> program executes the file as a bash script, causing a nuclear power
> plant to explode.

With respect, I think this is a bit drastic.

Anybody writing a program where the consequences of failure are so
catastrophic *should* care whether the file is valid UTF, should read
the documentation, and shouldn't just copy-paste.

I know people are stupid. Are they really *that* stupid? Should we not
implement PCRE_NO_UTFx_CHECK at all? Using it incorrectly can cause
crashes and problems in all modes. I am happy to beef up the warnings in
the docs.

> Do any of you happen to be on the mailing list for libcurl? A recent
> discussion is relevant. The subject line is "The Most Dangerous Code
> in the World". Due to widespread misunderstanding of the API, many
> programs using libcurl have made this error: "setting
> CURLOPT_SSL_VERIFYHOST to TRUE, will result in the SSL connection
> being insecure against a man-in-the-middle attacker". Sounds harmless,
> right?

The word "insecure" doesn't sound harmless to me!

> Given an option named CURLOPT_SSL_VERIFYHOST, wouldn't TRUE be
> better than FALSE? In fact it's supposed to be a three valued option,
> not boolean, and the value "1" is dangerous.

It is regretful that the C language does not have proper boolean
values/variables, but instead subverts ints.

Philip

--
Philip Hazel