Python String Immutability Broken!
ken at seehart.com
Mon Aug 25 12:43:01 CEST 2008
You can also use ctypes to globally change the value of integers less
than 101. Personally, I don't particularly like the number 14. I
changed it to 9 and I am much happier now.
I love ctypes. So cool. It's not supposed to be safe.
Life is either a daring adventure or nothing. Security does not
exist in nature, nor do the children of men as a whole experience
it. Avoiding danger is no safer in the long run than exposure.
*Helen Keller <http://www.quotationspage.com/quotes/Helen_Keller/>*
/US blind & deaf educator (1880 - 1968)/
Of course I would not hire anyone who believes this quote, other than
Helen Keller, if she were still with us.
It is quite possible to write a small program that works using abused
strings. But my life better not depend on it. Among other things, if
you use the abused string as a key anywhere, you will not get correct
results. Trying to change the length of the string will cause
disasters. Lengthening a string will corrupt memory, and shortening the
string will not shorten it but rather embed '\0' in it.
Hendrik van Rooyen wrote:
> Patrick Maupin <pmau....ail.com> wrote:
>> Very entertaining.
> Thanks. Nice to see that there is still some sense of humour
> left somewhere - its all been so serious here lately - people
> seem to forget that hacking is fun!
>> But let me get this straight: Are you just complaining that if you
>> pass a string to an arbitrary C function using ctypes, that that
>> arbitrary function can modify the string?
> Actually, I am not complaining - I am asking for advice on the side
> effects of what I am doing, which is replacing a bunch of bits
> in what is essentially an output bit field with the corresponding
> input bits at the same addresses read back from a simulated i/o
> bus structure. And I would also like to know if there is a better
> way of doing this.
> The C code actually works, doing what was intended - the \xff that
> one sees appearing back comes from the pullup resistors on the
> eBox's i/o. I can show that it is working by adding some resistance
> and capacitance (by holding the connector against my tongue) in which
> case I get a munged version of the fox back. (- evidently my tongue
> is not such a perfect communications medium as I would like to believe.)
> Passing the fox is actually deceptive and misleading, as in real
> use there would be no such correlation sideways across bits, as
> they are just representations of output lines.
> (Think "coils" in PLC jargon)
>> Because if you are, then I think you share a great deal of
>> responsibility for the death of that string -- sending the poor thing
>> to its grave through some unknown C function.
> This string is NOT dead - it is alive, and not even stunned -
> it just looks as if it is sleeping because of the \xff - which
> comes from the fact that there is no real hardware out there yet.
> The C functions are very simple ones actually - they just do
> what are essentially Linux I/O system calls - setting direction
> bits for a port (in or out) and then reading or writing the data.
> - Hendrik
More information about the Python-list