The C programmers’ disease

The C programmers disease has a long history.

A fundamental assumption in the design of the C language is that the programmer knows what dey am doing.

So, if you declare an array of numbers to be 5 numbers by 5 numbers, and then access the number in position 7,7, it will happily fetch the essentially random number in the memory location that corresponds to that position, IF it existed.

Unlike bondage and discipline languages like Pascal that make the opposite assumption.

VERY often seen as an arbitrary power of 2 e.g. you can define 256 colours for your web homepage.

Amazingly common in database design and storage allocation as well. e.g. An address line will NEVER be more than 64 chars long… tick tick tick.

C Programmer’s Disease: n.

The tendency of the undisciplined C programmer to set arbitrary but supposedly generous static limits on table sizes (defined, if you’re lucky, by constants in header files) rather than taking the trouble to do proper dynamic storage allocation.

If an application user later needs to put 68 elements into a table of size 50, the afflicted programmer reasons that he or she can easily reset the table size to 68 (or even as much as 70, to allow for future expansion) and recompile.

This gives the programmer the comfortable feeling of having made the effort to satisfy the user’s (unreasonable) demands, and often affords the user multiple opportunities to explore the marvelous consequences of fandango on core.

In severe cases of the disease, the programmer cannot comprehend why each fix of this kind seems only to further disgruntle the user.

Fandango on core: n.

[Unix/C hackers, from the Iberian dance] In C, a wild pointer that runs out of bounds, causing a core dump, or corrupts the malloc(3) arena in such a way as to cause mysterious failures later on.

It’s sometimes said to have ‘done a fandango on core’. On low-end personal machines without an MMU (or Windows boxes, which have an MMU but use it incompetently), this can corrupt the OS itself, causing massive lossage.

Other frenetic dances, such as the cha-cha or the watusi, may be substituted. See aliasing bug, precedence lossage, smash the stack, memory leak, memory smash, overrun screw, and core.

9 comments for “The C programmers’ disease

  1. August 29, 2012 at 06:10

    Proff Needham used to call it a “bogus resource”. You take something that should be limitless and turn it into a limited resource.

  2. August 29, 2012 at 06:55

    In 7th grade or lower computer terms, where my knowledge level might currently be, some things can be done to correct, some not.

    For example, this post itself had strange formatting when published and so, knowing that whatever you open with in html you must later close with, and knowing a taxonomy of code symbols [having them beside me in a list], I can alter the look.

    That’s CSS stuff, a far cry from messing with the PHP which, I’m given to understand, is also child’s play once you know the basics and just a language thing. I began learning it. I never venture into entering parameters unless it is a set table or whatever which has been used in this context before and is not an alien entry.

    There are also areas which are play-roundable and areas which you don’t go near. One of the problems for the 2nd or 3rd stage user is knowing when there have been overrides or not. In fact, in the colours on the site, I’ve put in my own overrides for uniformity.

    That’s way different to what the post is about. The fear of a fandango on core makes me ultra-cautious but I also fear that many amateur programmers are arrogant and have the C programmers’ disease.

    For example, one of the key people at this site sends many emails. Unfortunately, if it is text to use in a post, it has this maddening American limitation of 64 characters to the line. It’s maddening because when transferred to WP, which has some form of auto-wrap, the text comes out truncated on each line and then I have to go through every line in the post, changing it back to plain.

    It’s might be an issue of the Americans and how they format or it might be his email – haven’t got to the bottom of this. My techie friends tell me tales of people who think they understand and have university course knowledge but don’t actually know in deep terms. So they think something really cool and put it in, only to cause fandango.

    It’s the mindset which is the problem here, coupled with the imperfect knowledge. I consider myself safer because I won’t mess about and understand my limited knowledge – improving a bit each day.

  3. Wolfie
    August 29, 2012 at 10:40

    Most of the issues listed are “legacy”; that is they were restrictions placed on systems in a time when storage and power were limited. Now that hardware is much more powerful and cheaper there is no need for them but the old code persists because financial constraints prevent re-write or development has been shipped overseas where labour is cheap but sub-standard.

    You want free software, this is what you get.

  4. Chuckles
    August 29, 2012 at 11:19

    Perhaps I should point out that the above was in response to this –

  5. dearieme
    August 29, 2012 at 12:38

    “So, if you declare an array of numbers to be 5 numbers by 5 numbers, and then access the number in position 7,7, it will happily fetch the essentially random number in the memory location that corresponds to that position, IF it existed.”

    What a disastrously awful idea. Moronic. It means the code is essentially uncheckable since you can’t rule out such stuff.

  6. haiku
    August 29, 2012 at 16:49

    To underline Chuckles initial statement: “A fundamental assumption in the design of the C language is that the programmer knows what dey am doing.”

    Other languages exhibit similar ‘quirks’ though not nearly so bad e.g. in days of yore – where ‘yore’ may still be with us – the length of the record returned to a COBOL program was defined by the file creation parameters.

    So if your program’s buffer definition was shorter than that of the physical file any record read merrily overflowed the record buffer and continued on into the program proper …

    With regards to ‘moronic’: there are an endless number of methods to overcome the problem – including the immediate dismissal of the coder for using the algorithm quoted – however all result in a degradation of the program’s execution speed: and in C that’s a no-no

  7. dearieme
    August 29, 2012 at 17:16

    In My Day, the first requirement of programming wasn’t execution speed, it was No Cockups.

    You achieved good execution speeds by using clever algorithms.

    But In My Day, you often did the maths/algorithm design yourself, as well as the programming.

    There’s a price to pay for Division of Labour.

  8. August 29, 2012 at 21:29

    This discussion around two nearly defunct programming languages reminds me of something.

    A great time ago, IIRC in the second year of my employment – post BSc ARCS, I had a bit of a problem with one of my programs written in the ALGOL-60 programming language.

    That was after the definition of Pascal, but (so Wikipedia tells me) before the first implementation thereof. It was also before the publication of ‘Kernighan and Richie’ on ‘C’.

    My program reported ‘illegal instruction trap’. Being well brought-up, I knew that was almost certainly down to corruption of the program code by accessing outside of the bounds of an array: a thing that is/was/would be my fault. There were many arrays in my program (which was the implementation of an MFSK modulator/demodulator).

    So I set about checking the access of every array in the program, whilst also working on other stuff relating to experimental measurements of MFSK communications (involving a mini-van, a tent, putting up aerials in fields and humping lead-acid batteries).

    Anyway, after weeks of investigation, there was not a single array access in my program that had not been checked at run-time against the declared array lengths: and they all passed.

    At this point, I began to doubt my own competence in tracking down my own bugs. I went to the system manager with my problem. A day later all was solved.

    Someone had edited the (assembly language) code of the ALGOL-60 run-time environment. They had forgotten to restore a register. The error message was wrong. The actual error (it was that long ago) was that I had not requested enough memory for my program to run: something that required a 2-character correction on the job control language.

    With this great learning experience behind me (to stay sceptical on everything), I have subsequently found and avoided compiler bugs (present under some but not all optimisation options), diagnosed bugs in the code of others (related to assumed parameter values determined by position – a feature quite loved by definers of more modern languages), warned everyone I worked with that most computers most of the time detect floating point overflow, but not integer overflow. And many other things of importance relating to computer programs.

    So if you think bondage and discipline are the solutions to faulty programming technique, think again.

    You really need to know what the computer is doing, in translating your (often perfectly correct) code. Only then will you be able to determine what is wrong, why, and who is to blame.

    Scepticism is also useful when dealing with eco-enthusiasts – not least of and for the CAGW fallacy. Their main problem, IMHO, is the equating of existence of mechanism to it their knowing it is material in their chosen scenario: thanks be to God that most of them escape jury duty. On which, also, I must mention my most recent book purchase: The Cult of Statistical Significance: How the Standard Error Costs Us Jobs, Justice and Lives.

    Stay sceptical brothers and sisters: particularly of those who claim you are ignorant in ways they are not!

    Best regards

  9. haiku
    August 30, 2012 at 16:49

    Ah yes, many is the time that I have suffered as a result of an erroneous error message …

    The COBOL story (above) cost me a week of searching for the bug in someone else’s code.

    The matter was resolved when my cousin – also a COBOL programmer – came to see me and asked about the bug. After I had explained the issue he pointed to the faulty buffer definition and said “there’s your problem”: one minute to sort out the bug on which I had wasted the whole week.

    Seems he had been bitten by the same problem …

    Your advice – stay sceptical – is excellent. Unfortunately my younger colleagues – though some are excellent programmers – see the computer as a black box and believe that those who write compilers are infallible …

    And at least one thought that I was pulling his leg when I described a magnetic tape …

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.