Path: utzoo!attcan!uunet!mcsun!unido!mikros!mwtech!martin From: martin@mwtech.UUCP (Martin Weitzel) Newsgroups: comp.std.c Subject: Making C a little more 'foolproof' (was Re: Naming) Message-ID: <681@mwtech.UUCP> Date: 1 Mar 90 11:22:06 GMT References: <1990Feb23.184656.3110@siia.mv.com> <16021@haddock.ima.isc.com> gwyn@brl.arpa (Doug Gwyn) writes: >In article mcdaniel@amara.uucp (Tim McDaniel) writes: >>Are standard library names utterly and completely reserved, or can I >>fake it with #define, as in >> #define malloc(bytes) my_malloc(bytes, __FILE__, __LINE__) > [correct parts of the answer deleted] > >It would be better to use some name other than malloc for this macro. Yes and No - it depends on why I (or the poster) want to do this. IMHO, there's a big 'philosophical' difference between languages like C, which obliges the programmer to do *all* error checking (namely for "fopen", "malloc" a.s.o., which may only fail under 'unusual conditions') and PASCAL, which does much more 'holding hands' at the cost, that the programmer has no chance to regain control, if a FILE cannot be opened, a NEW cannot make memory available a.s.o. This often has lead to the general assumption, that C is an 'unsafe' language, because programmers may tend to ommit error checking (because they have learned PASCAL earlier than C and think, it's not necessary, because they think "I'll add it later" and forget to do so, or because they consider the situation a "never happens" one). There is much moaning about this 'insecurity of C', heard from novices (and people, who happen to have an other favorite language than C), but it's very seldom noticed, that it takes NOT MORE THAN 1 (ONE) HEADER-FILE and a few additions to the library, to rectify most of it. (It may be valuable to do this, if you plan to teach courses on C.) The header file does exactly, what the poster proposes (and I'm glad ANSI did not make it illegal): You substitute 'unsafe' library functions, say "foo", by macros of the same name, which call similar named functions "my_foo" as the original poster proposed, or "sfoo" as I prefere, where the "s" stands for "safe". The "s"-functions are defined in a separatly compiled module, and call the respective original library function (and hence must *not* #include the header file, which redefines the name). Besides that, they do some error checking, print diagnostics (for which the hidden arguments __FILE__ and __LINE__ are fine) and may abort the program. This approach seems most useful for learning C, because the novice can concentrate to get the syntax and algorithms right, without cluttering up the progam with code for error checking. (IMHO, this is the reason, why PASCAL stepped along this road and is - in an unaugmented version - useless for 'real life' programming, were you often have to undo some earlier operations, if a later operation is not succesfull.) But you can make this scheme more sophisticated and usable for production programming. You only need to call the error handlers from the "s"-functions via function pointers, that can be altered from outside (but should default to diagnostic messages and/or termination). If you extend this idea further (eg keep the error handlers for each logical level of functions in separate tables and calling them via double pointers) you may even easily switch tables. The bottom line is, that you can have much of ADA's or PL/1's exception handling added to C. It requires no changes to the syntax of C, you must only make use of those features, which are allready there. -- Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83