"It's very unusual for that to happen, but it's understandable," said Robert C. Krause, executive director of Emergency Services Consultants in Toledo, Ohio, who is familiar with the New York system. "I don't know if anyone would anticipate this because it's a highly technical thing. I think most public safety administrators would assume that their numbers are safeguarded."
/*
* This will never happen, and the routine is slow.
*
* validate_phone_number(phone_number);
* if (errno == EBADPHONENUM) {
* yell_at_verizon(errno, "moron");
* return EXIT_FAILURE;
* }
*/
* Changed exceptions so that they must now inherit from the built-in
Exception class. This allows for a general catch(Exception $e) statement
to catch all exceptions. (Andi, Zeev)
I used to be a PHP developer, but switched to python-based content management systems due to the elegance and ease of programming in python. However, I was interested to see how PHP had progressed since the last version, and read the article linked by Slashdot.
The main reason I initially dumped PHP was its atrocious error handling. Python and other more elegant languages use exception handling, which is much more elegant than checking return codes and setting error handlers.
I had read earlier than PHP 5 would include exception handling, but wouldn't include the "finally" clause. For programmers that understand and use exceptions, the finally clause is _very_ useful. I try to avoid using C++ simply because it doesn't have a finally clause (and no, the object destruction mechanism is not a good substitute).
So, I became very excited when I read the following:
Note that there is support for "catch all" and for the "finally" clause.
(http://www.php.net/zend-engine-2.php)
However, I couldn't find any examples showing the "finally" clause or the "catch all" clause in use.
So, I went grepping through CVS.
In the changelog for PHP, it is suggested that all exceptions _must_ inherit from a base 'Exception' class, which means that catching and exception of type 'Exception' is a basic "catch all". However, I couldn't find _any_ evidence in CVS that a "finally" clause has been introduced in PHP 5.
Has anyone here found evidence that the "finally" clause exists in PHP 5?
Delusions of creativity brought on by my tiredness (it was passed 4:00 AM). At the time, I thought that "various virii"/sounded/ better than "various viruses". Excuse the hacked-up English.:)
This just in! Windows users offer a bounty for Microsoft programmers that write buggy, insecure code that allows computers running Windows to be compromised by various virii! More on news at 11:00!
Re:Lesson #1: Don't use C or C++ for Secure Progra
on
Secure Programming
·
· Score: 1
Ack... I meant to preview that post. Apologies for the (accidental) lack of spatial consideration.
Re:Lesson #1: Don't use C or C++ for Secure Progra
on
Secure Programming
·
· Score: 2, Insightful
To start, the parent comment should be modded back up. The parent poster isn't a troll; (s)he just has strong opinions.
Onto the post...
Geez, how hard can this be? C and C++ are the only two major languages
on the market nowadays which allow array overflows, pointer dereferencing
into code, free creation of unsafe code, and other fun stupidities. As such,
they are easily the WORST LANGUAGES on the market for secure
programming.
This is a common programming fallacy. It's not the programming language that makes it easier to create a secure program; it's the programmer with a thorough understanding of security that makes the (infinitely approaching) secure program.
Sure, people will say oh, yeah, but you can be insecure in any
language. These people should have their CS degrees revoked.
They're right (and if you had your way, I'd have my piddly degree revoked in a few seconds:P)!
There are dozens of popular programs written in C/C++ in which security holes haven't been found, programs that are written carefully and thoroughly debugged by programmers that understand security. Programming languages like Python, Ruby, LISP, [... ad nauseum] make it easier to avoid common pitfalls (i.e. buffer overflows), but there are plenty of security holes that can be introduced into programs written in those languages.
Don't get me wrong. I'm a Python zealot, I like Ruby, and I think Modula-3 has (had?) the potential to be one of the best systems programming languages available (if not for the lack of tools associated with Modula-3). However, that doesn't change the fact that there are great C/C++ programmers out there that will write less buggy code in their lifetimes than many Python/Java/Ruby/[insert your favorite language of convenience] programmers that don't know the first thing about computer security.
I could apply your logic to language interpreters/compilers for some of the languages you mentioned (i.e. Java, Python, Ruby, etc.). Is the Python interpreter less secure than a Python program because the interpreter was written in C? If the interpreter is insecure, then what does that say about Python programs when they're being interpreted by the interpreter? A program is secure if it's behavior is predictable, given a certain set of actions.
Slashdot Mirror
#include <errno.h>
#include <phone/system.h>
#include <stdlib.h>
#include <stupid/verizon.h>
int main(int argc, char *argv[])
{
- char *phone_number = get_phone_number();
/*
}* This will never happen, and the routine is slow.
*
* validate_phone_number(phone_number);
* if (errno == EBADPHONENUM) {
* yell_at_verizon(errno, "moron");
* return EXIT_FAILURE;
* }
*/
change_phone_number(phone_number);
return EXIT_SUCCESS;
> Try C# - seriously.
:)
Thanks, but I'm quite happy with Python.
I filed a bug report with the PHP folks regarding the mention of the finally clause a few hours ago. They've now fixed the document to read:
Note that there is support for "catch all" but not for the "finally" clause.
(http://www.php.net/zend-engine-2.php)
So, there is no finally clause in PHP 5. How unfortunate.
Hmmmm...
From http://www.php.net/ChangeLog-5.php#5.0.0RC1:
Version 5.0.0 Beta 4
12-Feb-2004
* Changed exceptions so that they must now inherit from the built-in
Exception class. This allows for a general catch(Exception $e) statement
to catch all exceptions. (Andi, Zeev)
I used to be a PHP developer, but switched to python-based content management systems due to the elegance and ease of programming in python. However, I was interested to see how PHP had progressed since the last version, and read the article linked by Slashdot.
The main reason I initially dumped PHP was its atrocious error handling. Python and other more elegant languages use exception handling, which is much more elegant than checking return codes and setting error handlers.
I had read earlier than PHP 5 would include exception handling, but wouldn't include the "finally" clause. For programmers that understand and use exceptions, the finally clause is _very_ useful. I try to avoid using C++ simply because it doesn't have a finally clause (and no, the object destruction mechanism is not a good substitute).
So, I became very excited when I read the following:
Note that there is support for "catch all" and for the "finally" clause.
(http://www.php.net/zend-engine-2.php)
However, I couldn't find any examples showing the "finally" clause or the "catch all" clause in use.
So, I went grepping through CVS.
In the changelog for PHP, it is suggested that all exceptions _must_ inherit from a base 'Exception' class, which means that catching and exception of type 'Exception' is a basic "catch all". However, I couldn't find _any_ evidence in CVS that a "finally" clause has been introduced in PHP 5.
Has anyone here found evidence that the "finally" clause exists in PHP 5?
Delusions of creativity brought on by my tiredness (it was passed 4:00 AM). At the time, I thought that "various virii" /sounded/ better than "various viruses". Excuse the hacked-up English. :)
This just in! Windows users offer a bounty for Microsoft programmers that write buggy, insecure code that allows computers running Windows to be compromised by various virii! More on news at 11:00!
Ack ... I meant to preview that post. Apologies for the (accidental) lack of spatial consideration.
To start, the parent comment should be modded back up. The parent poster isn't a troll; (s)he just has strong opinions.
Onto the post ...
Geez, how hard can this be? C and C++ are the only two major languages
on the market nowadays which allow array overflows, pointer dereferencing
into code, free creation of unsafe code, and other fun stupidities. As such,
they are easily the WORST LANGUAGES on the market for secure
programming.
This is a common programming fallacy. It's not the programming language that makes it easier to create a secure program; it's the programmer with a thorough understanding of security that makes the (infinitely approaching) secure program.
Sure, people will say oh, yeah, but you can be insecure in any
language. These people should have their CS degrees revoked.
They're right (and if you had your way, I'd have my piddly degree revoked in a few seconds :P)!
There are dozens of popular programs written in C/C++ in which security holes haven't been found, programs that are written carefully and thoroughly debugged by programmers that understand security. Programming languages like Python, Ruby, LISP, [... ad nauseum] make it easier to avoid common pitfalls (i.e. buffer overflows), but there are plenty of security holes that can be introduced into programs written in those languages.
Don't get me wrong. I'm a Python zealot, I like Ruby, and I think Modula-3 has (had?) the potential to be one of the best systems programming languages available (if not for the lack of tools associated with Modula-3). However, that doesn't change the fact that there are great C/C++ programmers out there that will write less buggy code in their lifetimes than many Python/Java/Ruby/[insert your favorite language of convenience] programmers that don't know the first thing about computer security.
I could apply your logic to language interpreters/compilers for some of the languages you mentioned (i.e. Java, Python, Ruby, etc.). Is the Python interpreter less secure than a Python program because the interpreter was written in C? If the interpreter is insecure, then what does that say about Python programs when they're being interpreted by the interpreter? A program is secure if it's behavior is predictable, given a certain set of actions.
The Slashdot T-Shirt contest is only a prelude to the much more widely anticipated Slashdot _Wet_ T-Shirt Contest!
... geek boobs.
Mmmm