Path: utzoo!attcan!uunet!snorkelwacker!mit-eddie!apollo!perry From: perry@apollo.HP.COM (Jim Perry) Newsgroups: comp.software-eng Subject: Re: problems/risks due to programming language, stories requested Message-ID: <48f470ee.20b6d@apollo.HP.COM> Date: 2 Mar 90 15:27:00 GMT References: <6960@internal.Apple.COM> <48f0d9c2.20b6d@apollo.HP.COM> <2935@goanna.oz.au> Sender: root@apollo.HP.COM Reply-To: perry@apollo.HP.COM (Jim Perry) Organization: Hewlett-Packard Company, Apollo Division; Chelmsford, MA Lines: 95 In article <2935@goanna.oz.au> ok@goanna.oz.au (Richard O'keefe) writes: >In article <48f0d9c2.20b6d@apollo.HP.COM>, perry@apollo.HP.COM (Jim Perry) >offers a list of 8 mistakes he made. Before commenting, I would remind >you that I am not a C bigot; I'm not an anti-C bigot, however I am an anti-(C-bigot). I was simply presenting a post-mortem analysis of the specific errors I made, with commentary on whether the compiler or language could have helped me detect or avoid them. I was explicit in several places that a different C compiler (or interpreter, or lint, though I didn't mention these by name, or, as it happens, the same C compiler with a higher level of informative output) could have done so. Very few of my bugs were explicitly C related in that no conceivable C translator could have detected them, nor did I make that claim. >> 2. I wanted to fill in a record whose structure was something like: >Not a C problem. Instead of using variable length fields, which C >quite explicitly doesn't support, it would be better to use pointers. >I think this mistake should be counted as refusal to do things the C way. Patient: Doctor, it hurts when I do this! Doctor: Then don't do that! False assumption. It happens that this program manipulates records with variable-length parts, which ultimately must reside in a database in contiguous format. While actively manipulating the data, it is represented in a C-natural way as pointers and lists, but coming off the disk and going back on it has to be turned into a contiguous form. >> Other languages, however, would have allowed me to describe such a >> structure within the language (PL/I, for one). > >It's worth pointing out that PL/I is not a strongly typed language >(*much* weaker than C) >and although it has record variables it does not have record types. It also uses funny names for integers. What do either of these comments have to do with the basic premise that while C "quite explicitly doesn't support" variable length fields in structures, other languages do? I didn't say "PL/I is better than C", I used it as an example. If C supported this capability it would have simplified my life and avoided bugs in my program. >>In a system >>with runtime array bounds checking, this would have been detected >>quickly and painlessly. >Note that some systems... This is all absolutely irrelevant. I didn't advocate any particular language or implementation, just that a feature, array bounds checking, which many languages/implementations support, would have helped me. Naturally I implied that such an implementation would have been such that it would have detected my bug; I've used such systems. >> 7. I had one bug caused by omission of an item in an initializer list >> for a struct (a vector of function pointers). The compiler could have >> caught that if the language didn't allow partial initializer lists. > >Caught by a feature, I'm afraid. It's a truism in this business that one programmer's "feature" is another's "bug". In any event I'm unswayed by your workaround kludges. That you've found the down side of this "feature" a sufficient impediment to think of two separate workarounds doesn't speak well for its value. >> Overall, that's 8 bugs or classes of bugs. 5 of the 8 could have been >> avoided or detected by a smarter compiler or a different language. > >My totals are >4 Not a C problem >1 Can be avoided by exploiting the preprocessor >2 Would have been caught by Lint or some existing compilers >1 Would have been caught by a C interpreter In other words, you restated my conclusion (after blithely deciding that I had no business wanting to deal with variable-length fields in records, which I reject): 3 Not a C problem (i.e. would have been a bug in other likely implementation languages, were not detectable by C translator) 1 "C quite explicitly does not support" (i.e. could have been avoided by a different language) 4 could have been detected by smarter compiler/translator, or a different language. Sounds like we're in pretty close agreement, except to the extent that you seem to think I'm out to get C, or that I'm promoting some other language. I'm just observing that better tools (than I happened to take advantage of) could have helped me save debugging time on a specific program, by a factor of over 50%. - Jim Perry perry@apollo.hp.com HP/Apollo, Chelmsford MA This particularly rapid unintelligible patter isn't generally heard and if it is it doesn't matter.