Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!rochester!udel!mmdf From: V61%DHDURZ1.BITNET@cunyvm.cuny.edu (Ronald Lamprecht) Newsgroups: comp.os.minix Subject: Re: Future of Minix Message-ID: <19978@louie.udel.EDU> Date: 18 Jul 89 18:10:28 GMT Sender: mmdf@udel.EDU Lines: 37 Concerning my proposal to introduce debugging stuff into the library I saw the following responses: Andy Tanenbaum (ast@cs.vu.nl) wrote: >Argh! I think #ifdefs make code very hard to read and ugly. I am not all >that wild about the idea. I admit that #ifdef #else #endif constructs are ugly and hard to read, because they contain two different solutions of the same problem. But common #ifdef DEBUG #endif shouldn't be that ugly. They contain unique code that may even be of some interest if you omit it, because they show common sources of errors. Furthermore there are ways to hide this #ifdef'ed stuff as Wayne Hayes showed: >Oh, c'mon. There are very clean ways to do this. Gary Mills asked: >Would not _lint_ be a better solution ? No -- lint is a very useful tool, but neither lint can do everything that could be done with a debugging library nor can a run time error checking detect all errors that lint can. For example lint can detect a LW argument instead of a word (integer) argument, but the resulting run-time value may be a valid and possible argument so that the error cannot be detected. On the other hand all argument types may be ok and lint be happy, but the actual value may be impossible and cause a bus-error or something else what is difficult to debug. Furthermore it would be possible to introduce additional stack checking during the debugging phase of a program with such a special library. By the way if you have a PD lint version for Minix please post it ! Harry Gross wrote: >I _LIKE_ it. Alot. I'm happy that I am not alone in this world. Bitnet: V61@DHDURZ1 Ronald Lamprecht UUCP: ...!unido!DHDURZ1.bitnet!V61 Theoretische Physik ARPAnet: V61%DHDURZ1.BITNET@CUNYVM.CUNY.EDU (Heidelberg, West Germany)