Python secure?

[Reid Nichol]

Terry Reedy wrote:
> "Peter Hansen" <peter at engcorp.com> wrote in message
> news:NIydnd-skK0q173cRVn-ow at powergate.ca...
> 
>>Reid Nichol wrote:
>>
>>
>>>Terry Reedy wrote:
>>>
>>>
>>>>... compiled C can be terribly insecure relative to
>>>>Python.  C has dangerous functions like strcpy() which, if used with
>>>>external input, can make a program subject to buffer overrun exploits
>>>>that
>>>>can do explosive damage.
>>>
>>>But this doesn't make C an insecure language.  No language is either
>>>secure nor insecure.  It's what the programer does with it that
> 
> matters.
> 
> Yes, and in a later sentence, I said something about smarter programmers
> and code check policies.  Indeed, by the mid-1980s, I knew that giving
> control of copying to the block copied, by copying until the block
> contained a null byte, could be dangerous.  But somewhere around 2000,
> Microsoft shipped product that did exactly that with data taken off the
> Internet.
And because some M$ employee did something sloppy it is an implication 
that C is bad.  Hell, even strncpy can be dangerous.  How many times do 
I have to say the responsibility is the programmers, *not* the language.

And what language is Python programmed in... oh yah, C.  Perhaps people 
shouldn't talk about how poorly secure C and then go off to how secure 
Python is when Python is written in C.  Houses built on sand...

> Especially if a programmer is rewarded for faster code -- which one write
> by copying dangerously -- and pushing the hidden costs off onto customers.
If a programmer wanted to finish a program quickly then then shouldn't 
use C.  If the programmer is required to use C then (s)he is working for 
a bad company that knows nothing of such things and would have produced 
poor software from the beginning because of such silly things.