Gabriel Dos Reis wrote: > I would suggest you give more thoughts to the claims made in > http://www.seas.upenn.edu/~sweirich/types/archive/1999-2003/msg00298.html
I'm not sure I understand this. Looking at "Example 2", where C is claimed to be "C-safe", he makes two points that I disagree with. First, he says Unix misimplements the operations semantics of C. It seems more like Unix simply changes the transition system such that programs which access unmapped memory are terminal. Second, he says that he hasn't seen a formal definition of C which provides precide operational semantics. However, the language standard itself specified numerous "undefined" results from operations such as accessing unallocated memory, or even pointing pointers to unallocated memory. So unless he wants to modify the C standard to indicate what should happen in such situations, I'm not sure why he thinks it's "safe" by his definition. There is no one "q" that a "p" goes to based on the language. He's confusing language with particular implementations. He seems to be saying "C is safe, oh, except for all the parts of the language that are undefined and therefore unsafe. But if you just clearly defined every part of C, it would be safe." It would also seem to be the case that one could not say that a program "p" is either terminal or not, as that would rely on input, right? gets() is "safe" as long as you don't read more than the buffer you allocated. What's the difference between "safe" and "well-defined semantics"? (Ignoring for the moment things like two threads modifying the same memory at the same time and other such hard-to-define situations?) -- Darren New / San Diego, CA, USA (PST) Native Americans used every part of the buffalo, including the wings. -- http://mail.python.org/mailman/listinfo/python-list