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.
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.