in the spirit of Halloween. Vlad Dracul effectively demonstrated the use of pointers.
-----Original Message----- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of John Campbell Sent: Wednesday, October 29, 2003 9:52 AM To: [EMAIL PROTECTED] Subject: Re: Memory access faults. I recall the words of one sage: "Never test for an error you don't know how to handle." I've also heard a story about NASA's message switching network (when it was on UNIVAC 494s) about losing sync and all nodes reporting "the system is red". Even "impossible" errors happen. I've also seen some ludicrous levels of trust in code from College graduates, who would use long pointer dereferences over and over again... and not have a local copy of the ultimate pointer for the end-structure. "If you do not pay attention to pointers they won't pay attention to you." -------------------- John R. Campbell, Speaker to Machines (GNUrd) {813-356|697}-5322 Adsumo ergo raptus sum MacOS X: Because making Unix user-friendly was easier than debugging Windows. ----- Forwarded by John Campbell/Tampa/IBM on 10/29/2003 09:48 AM ----- "Hall, Ken (IDS ECCS)" To: [EMAIL PROTECTED] <[EMAIL PROTECTED]> cc: Sent by: Linux on Subject: Re: [LINUX-390] Memory access faults. 390 Port <[EMAIL PROTECTED] IST.EDU> 10/29/2003 08:35 AM Please respond to Linux on 390 Port Well, actually, so do I, but we're a vanishing species. > -----Original Message----- > From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of > Paul Hanrahan > Sent: Tuesday, October 28, 2003 6:12 PM > To: [EMAIL PROTECTED] > Subject: Re: [LINUX-390] Memory access faults. > > > I do > > -----Original Message----- > From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On > Behalf Of Hall, > Ken (IDS ECCS) > Sent: Tuesday, October 28, 2003 3:06 PM > To: [EMAIL PROTECTED] > Subject: Re: Memory access faults. > > > Recovery is only as good as the language framework allows it to be. > Compilers insulate you from the data and the hardware, and > reduce your level > of control over how errors are handled. > > But that's part of what you're buying by using a compiler in the first > place: Not to have to worry about all those "little details". > > Assembler programs have access to interrupt exits that allow recovery > routines to get control. An infinitely smart programmer > could conceivably > write enough code to fix or recover from ANY failure, but how > many of THOSE > are there? And who writes in assembler anymore anyway? > > > -----Original Message----- > > From: Linux on 390 Port [mailto:[EMAIL PROTECTED] > Behalf Of > > David Boyes > > Sent: Tuesday, October 28, 2003 2:52 PM > > To: [EMAIL PROTECTED] > > Subject: Re: [LINUX-390] Memory access faults. > > > > > > > The problem with laying this at the feet of the application > > > programmer is that they are not perfect, and when the > program fails > > > it actually the end user that suffers. > > > > Unfortunately, that's about the only place it *can* go. Users can't > > (or shouldn't be able to) change the code on the fly, or, if they > > can, they're > > better than the developer -- or at least, a lot more bored > > and have way too > > much free time. > > > > Methinks that it mostly results from not probing your > environment at > > startup to determine what the limitations are, and then doing more > > rigorous checking > > that you don't violate those limits during operation. Way too many > > programmers assume infinite resources and don't cope with > > failure to acquire > > same. > > > > While we're airing pet peeves: why do people assume that changing > > programming languages will somehow fix this problem? It's just as > > possible to write rotten Java as rotten C or Fortran (in fact, it's > > possible to write > > bad Fortran in *any* programming language...8-)), and IDE's > > and all the > > other stuff doesn't fix bad programming practices any more > > than a fancy > > grease gun fixes seized bearings. It helps, but fused is > still fused. > > > > (yes, it's been Tuesday all over. grump.) > > > > -- db > > > Confidentiality Warning: This e-mail contains information intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, any dissemination, publication or copying of this e-mail is strictly prohibited. The sender does not accept any responsibility for any loss, disruption or damage to your data or computer system that may occur while using data contained in, or transmitted with, this e-mail. If you have received this e-mail in error, please immediately notify us by return e-mail. Thank you.
