wex@SW.MCC.COM (Alan Wexelblat) (07/07/88)
Alan Lovejoy wrote: > According to Barry Cornelius's posting on the subject, the BSI proposal > currently on the table is "CONVERT(CARDINAL, -1)" as the syntax for a > "meaning-preserving" conversion. In this case the "value" is an exception. > What an "exception" is, is formally undefined. It is expected to be either > a no-op, a program abort or a trap to a debugging tool. This strikes me as a singularly *bad* idea. What on earth do we think "meaning" is if something "means" something undefined (in this case an exception)? Since the type of the function CONVERT is pretty floppy anyway, why not add an out-of-band signal (like EOF) to denote a value outside the range of possible conversions? I hope we're not going the way of C which thinks it's acceptable to give "an exception" (core dump) every time some poor programmer passes NULL to strlen()! --Alan Wexelblat ARPA: WEX@MCC.COM UUCP: {harvard, gatech, pyramid, &c.}!sally!im4u!milano!wex "How do we measure the distance between Ken Kesey and Carlos Lehder?" -- Hunter Thompson
heiser@ethz.UUCP (Gernot Heiser) (07/12/88)
In article <8807071341.AA09718@banzai-inst.sw.mcc.com> Info-Modula2 Distribution List <INFO-M2%UCF1VM.bitnet@jade.berkeley.edu> writes: >I hope we're not going the way of C which thinks it's acceptable to give "an >exception" (core dump) every time some poor programmer passes NULL to >strlen()! If every program bug would immediately force a program dump debugging would be a piece of cake. But I know, some people like to debug... So, long live the FORTRAN philosophy: "Division by zero? Set the result to zero and continue..." -- Gernot Heiser <heiser@iis.UUCP> Phone: +41 1/256 23 48 Integrated Systems Laboratory CSNET/ARPA: heiser%ifi.ethz.ch@relay.cs.net ETH Zuerich EARN/BITNET: GRIDFILE@CZHETH5A CH-8092 Zuerich, Switzerland EUNET/UUCP: {uunet,mcvax,...}!iis!heiser
wex@SW.MCC.COM (Alan Wexelblat) (07/14/88)
I said: >I hope we're not going the way of C which thinks it's acceptable to give "an >exception" (core dump) every time some poor programmer passes NULL to >strlen()! Gernot Heiser replied: > If every program bug would immediately force a program dump debugging > would be a piece of cake. But I know, some people like to debug... I don't think that's the right philosophy to program into support-library routines. In most cases, I intended to pass a null string; if I use the C constant NULL, I get a core-dump. If I use a literal null string ("") I get what I wanted, which was a length of zero. This is more a 'religion' argument but it relates back to the original point of what to do when type-converting routines get a value that's outside the range of defined values for the target type. My opinion is that these routines should return an out-of-band signal which the programmer could then test for. Core dumping or other uncatchable program exception is, in my opinion, a *very* poor way of handling errors. --Alan Wexelblat ARPA: WEX@MCC.COM UUCP: {harvard, gatech, pyramid, &c.}!sally!im4u!milano!wex "How do we measure the distance between Ken Kesey and Carlos Lehder?" -- Hunter Thompson
darryl@ism780c.isc.com (Darryl Richman) (07/14/88)
In article <8807071341.AA09718@banzai-inst.sw.mcc.com> Info-Modula2 Distribution List <INFO-M2%UCF1VM.bitnet@jade.berkeley.edu> writes: >I hope we're not going the way of C which thinks it's acceptable to give "an >exception" (core dump) every time some poor programmer passes NULL to >strlen()! I only wish most C implementations did do this! Passing NULL to strlen() is WRONG. It DESERVES a core dump. But brain damaged BSD code (amongst other brain damaged code) does it all the time. This is not so wonderful when it needs to run on brain damaged machines such as the 286! And AT&T seems to have picked up the habit now as well! ... I'm sorry. I know this is the Modula 2 forum and that it has a commendably high signal to noise ratio, which I'm hurting with this posting, but I have spent 3.5 years explaining this and it just punched my button. --Darryl Richman -- Copyright (c) 1988 Darryl Richman. The views expressed are the author's alone. INTERACTIVE Systems Corporation -- An Eastman Kodak Company ...!{kodak | cca!ima | sdcrdcf}!ism780c!darryl or darryl@ism780c.isc.com "For every problem, there is a solution that is simple, elegant, and wrong." -- H. L. Mencken