From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,fc050a66c3b5d87d X-Google-Attributes: gid103376,public X-Google-Thread: 1094ba,86e8c626be2471ae X-Google-Attributes: gid1094ba,public From: "James Giles" Subject: Re: F9X twister & ADA (was: n-dim'l vectors) Date: 2000/04/12 Message-ID: #1/1 X-Deja-AN: 610273750 References: <8cctts$ujr$1@nnrp1.deja.com> <38EA0440.1ECBC158@ncep.noaa.gov> <38ED4ECA.ADB698C9@sdynamix.com> <38F28A85.53809F39@sdynamix.com> <38F2C1DC.5538F9F0@research.canon.com.au> <5jJI4.297$PV.9915@bgtnsc06-news.ops.worldnet.att.net> <38F3D1D3.416B3493@research.canon.com.au> <85SI4.4008$fV.338113@bgtnsc05-news.ops.worldnet.att.net> <38F3F803.A4A56259@research.canon.com.au> <38F41313.DAF90E74@research.canon.com.au> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 X-Complaints-To: abuse@worldnet.att.net X-Trace: bgtnsc06-news.ops.worldnet.att.net 955559447 12.74.2.32 (Wed, 12 Apr 2000 17:10:47 GMT) Organization: AT&T Worldnet NNTP-Posting-Date: Wed, 12 Apr 2000 17:10:47 GMT Newsgroups: comp.lang.fortran,comp.lang.ada Date: 2000-04-12T00:00:00+00:00 List-Id: Geoff Bull wrote in message <38F41313.DAF90E74@research.canon.com.au>... ... >> And, >> branching to a handler probably loses all of the register contents >> that were present when the error arose. >I'm missing something. >By my definition of quit immediately you lose the contents of registers too. Those are (should be) in the drop-file, core file, or whatever is generated on your system that the debugger gets to look at when a program abnormally terminates. If the program continues to run *after* the error is detected, this information reflects the state the program is in when it *does* finally terminate (ie. after "graceful" termination). >> The buffers are inside the system and not part of my process >> image anyway. Systems which >> throw away I/O buffer information when a process terminates >> are seriously broken. > >What about buffered io and user defined buffering? Like all parts of the program's state, those are all still present *in* the debugging file. You can inspect them there. >> Like the possibility >> of sending yourself a KILL signal. > >Well, I'll admit to once doing this in a C program. >But it seems amazingly ugly compared to simply raising an exception, >to get precisely the same outcome. I think undocumented exceptions are clearly the ugliest way to accomplish this. Any public property of a procedure which isn't explicitly declared - by direct requirement of the language definition - is probably a bad idea. > And sending signals is not portable (especially to bare hw with no OS). And, sending signals would be perfectly portable if the language standard required them. How bare is the hardware? If it's all *that* bare, it won't support I/O or exceptions either. >Of course you have no more way of knowing which library routines might >send signals than you do of knowing which might raise exceptions. Why not? The fact that a routine sends a signal can be explicitly declared (by requirement of the language, even). But, since the semantics of signals isn't attached to the procedure-call chain, there's no need to declare this fact for each procedure that calls the one that sends the signal. Signals are, explicitly, messages to the process as a whole. They are not messages to the nearest active caller that has a handler defined. -- J. Giles