🚀 go-pugleaf

Steve Clamage (clamage@Eng.Sun.COM) wrote:
: In article 5vh@galaxy.ucr.edu, thp@cs.ucr.edu (Tom Payne) writes:
: >Steve Clamage (clamage@Eng.Sun.COM) wrote:
: >: You can't do anything useful in portable code with uninitialized
: >: pointers, or pointers which point to objects which are no longer
: >: available. The standard allows the implementation a great deal of
: >: leeway in trying to help by identifying such invalid uses.
: >
: >.... just as for arithmetic exceptions, which also engender "undefined
: >behavior."  But why the leeway to, say, reformat the disk, rather
: >than specifying the normal practice, which is to invoke a signal
: >handler, thereby, keeping the behavior defined?
: 
: Why should raising a signal be "normal practice"? Why not throwing an
: exception? What about time-critical programs which would rather risk an

Throwing an exception would be incompatible (or of marginal compatibility)
with C.  ( Too bad signal handlers can't throw exceptions ;-) )

: invalid pointer than pay the penalty of checking every pointer for validity?

Right!  That signal should be optional, not mandatory.  But, perhaps,
the question of whether and when to issue a signal is viewed as a 
quality-of-implementatino issue.  If so, then the implementation 
already has all the leeway it needs without opening the door to 
"undefined behavior."

Tom Payne (thp@cs.ucr.edu)
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]