I agree completely, but I come from an Assembler background where you HAD to sanity check EVERYTHING. The volume of "buffer overflow" issues in C programs boggles my mind. Even after I started coding in C, I still maintained a similar level of paranoia regarding input validation. It's not like it's all that hard to limit the size of what you accept, folks!
But some languages make it hard to implement certain kinds of checking properly. I've seen, for example, Cobol programs fail with 0C7 errors because some file field that was supposed to contain packed data doesn't. Certain assumptions are made, but occasionally things go wrong. So what SHOULD the application do about something like that? The answer goes back to that point I made in an earlier item about data integrity. If you don't KNOW what the field is supposed to contain, stop everything, report the failure, and let someone fix it. It seems inconvenient, but in the long run, often it's the safest course. > -----Original Message----- > From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of > David Boyes > Sent: Wednesday, October 29, 2003 8:48 AM > To: [EMAIL PROTECTED] > Subject: Re: [LINUX-390] 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". > > I don't disagree that having the compiler worry about some > things is OK; > it's more the assumption that "oh, this is Java so I don't > have to do return > code checking or worry about that 10G malloc() call on a > small machine" that > gets me miffed. No matter what language you use, there's > still some basic > sanity checking that has to be done to ensure stability, and > it's getting > rarer and rarer. > > > An infinitely smart programmer > > could conceivably > > write enough code to fix or recover from ANY failure, but how > > many of THOSE > > are there? > > Nobody's asking for perfection, but stupid little stuff like > not checking > arguments for sanity or indexing off the end of a string > because you're too > lazy to check the length before you increment is just lousy style. > Eradicating code like that is a moral imperative. > > > And who writes in assembler anymore anyway? > > Still a fair amount of it for those of us doing embedded > work. :caveman. Me > Make Hardware Go. Ugh. :ecaveman. > > -- db >
