Landmines and other hidden language bugs
Some programmers balk at the idea that programming languages contain bugs, built-in if you please. The simple proof is to look at any manual for a language from a major vendor of software. Even Hewlett Packard has hundreds of bugs listed in COBOL manual. The Report Writer in several versions of COBOL had severe bugs. Programmers avoid the bugs by avoiding the Report Writer. Instead, the programmers wrote their own paradigms. After getting an original working well, the programmer made to reports by copying the working report. The point is that programmers should avoid landmines.
Bad Language Implementation
In MS Excel, in formulas, the function Find(text, target) has a sever oddity. If the text does not occur in the target, the function returns #N/A, which requires special handling. A value of 0 would be more useful.
Similarly, in MS Excel, 2013, the following statement does not throw an error: if len(some_string) = "j" then
Stack Errors
For many years, the C programming language had a bug that allowed a long string to be copied into a short string. The result was that memory near the short string was over-written. The consequences were unpredictable. Some of the crashes broke web security.
Garbage Collection Errors
Several languages including C had a bug when a file was closed. The closure routine behind the close command did not release the temporary memory back to the system. If the system was re-booted frequently, this error had no consequence. However, when a system ran for days and opened thousands of files, the system crashed for lack of temporary memory.
A database system called Filemaker has an error when its limited free-space fills. After writing a certain number records to its storage, the program begins to overwrite the indices. Then Filemaker crashes. The clerk can mostly recover the data by performing a reload, which can take hours. The vendor recommends frequent reloads before corruption occurs.
MS Word and OpenOffice have had similar errors where working storage becomes corrupt after too many operations. The solution is to save regularly and to exit the program after long periods of modifications to the document.
Bad Language Implementation
In MS Excel, in formulas, the function Find(text, target) has a sever oddity. If the text does not occur in the target, the function returns #N/A, which requires special handling. A value of 0 would be more useful.
Similarly, in MS Excel, 2013, the following statement does not throw an error: if len(some_string) = "j" then
Stack Errors
For many years, the C programming language had a bug that allowed a long string to be copied into a short string. The result was that memory near the short string was over-written. The consequences were unpredictable. Some of the crashes broke web security.
Garbage Collection Errors
Several languages including C had a bug when a file was closed. The closure routine behind the close command did not release the temporary memory back to the system. If the system was re-booted frequently, this error had no consequence. However, when a system ran for days and opened thousands of files, the system crashed for lack of temporary memory.
A database system called Filemaker has an error when its limited free-space fills. After writing a certain number records to its storage, the program begins to overwrite the indices. Then Filemaker crashes. The clerk can mostly recover the data by performing a reload, which can take hours. The vendor recommends frequent reloads before corruption occurs.
MS Word and OpenOffice have had similar errors where working storage becomes corrupt after too many operations. The solution is to save regularly and to exit the program after long periods of modifications to the document.