Who needs exceptions (was Re: Two languages, too similar, competing in the same space.)

[Andreas Kostyrka]

On Sun, Dec 30, 2001 at 11:14:36AM -0500, Roy Smith wrote:
> It's also possible to write memory leaks in python.  Consider something 
> like:
> 
> packetLog = []
> while 1:
>    request = getPacketFromSocket()
>    packetLog.append (request)
>    doStuffWithPacket (request)
> 
> It's pretty dumb to write something like that, but it certainly is a memory 
> leak.
Nope, it's not. It's just an algorithm that needs unbounded memory.
A memory leak happens if you somewhere forget about "memory". Basically
something like this:

const char *someFunc(const char *instr) {
  char *interBuf=malloc(strlen(instr)+1);
  
  return instr;
}

Now nobody ever will able to find this block of memory, as it's pointer has
been lost. The difference to the above python code is, that python will
free the memory when the code block is left. (In your example this could
happen because of exception when the socket is shut down.)

There are basically only 2 ways to make Python memory leak:
1.) Leaky C modules. Some are badly written, others access an API that makes
    wrapping it impossible without some leaks.
2.) [Older versions only] Circular references.
    class Circular:
        def __init__(self):
            self.circular=self

IMHO, there is a huge difference between buffer overflows and exec/eval:
-) exec/Eval just behave like documented, and like some "functions" might
   pose security risks if passed untrusted data.
-) buffer overflows (basically fooling around with pointers) OTOH makes
   the code do completly unexpected things. Basically it breaks the
   "virtual" virtual machine. This is almost impossible in Python.
   (There are always C language modules ;) )

C and Python both expose potentially unsecure interfaces. And this is well,
because it is needed to do real work.
C OTOH exposes many additional unsafe interfaces that wouldn't have to be
unsafe by their semantic needs. They are just unsafe because nobody
did think when defining the API. (Example: strcat versus strncat)
This is documented by a number standard library functions that are shadowed
by a second set of functions that do the same thing, but are "safe".

For some interesting thoughts about runtime safety, one should consider
Modula3, which does have the safe/unsafe concept explicitly in the language.
(It's also an example for a safe enviroment that is compareable to C in
 performance, as it checks only a small number of constructs at runtime.)

Regards,

Andreas