Content deleted Content added
m Bot: Converting bare references, see FAQ |
→Memory allocation: My biggest beef with C. That and C strings of course. |
||
Line 54:
Automatically and dynamically allocated objects are not necessarily initialized; they initially have indeterminate values (typically, whatever [[Bit|bit pattern]] happens to be present in the [[Computer storage|storage]], which might not even represent a valid value for that type). If the program attempts to use such an uninitialized value, the results are undefined. Many modern compilers try to detect and warn about this problem, but both [[Type I and type II errors|false positives and false negatives]] occur.
Another common problem is that heap memory has to be manually synchronized with its actual usage in any program for it to be reused as much as possible. For example, if the only pointer to a memory allocation goes out of scope or has its value overwritten before <code>[[malloc|free()]]</code> has been called, then that memory cannot be recovered for later reuse and is essentially lost to the program, a phenomenon known as a ''[[memory leak]].'' Conversely, it is possible to release memory too soon and continue to access it; however, since the allocation system can re-allocate or itself use the freed memory, unpredictable behavior is likely to occur when the multiple users corrupt each other's data. Typically, the symptoms will appear in a portion of the program far removed from the actual error
This issue can also arise when using third party libraries. Often a function will return a pointer to a structure for the library user to use. Sometimes the pointer is to an internal static object of the library, and sometimes it is to a newly allocated object. Often it is not specified which is the case, leading to the previously described situations. Such issues can be solved in languages with [[garbage collection (computer science)|automatic garbage collection]] or [[resource acquisition is initialization|RAII]].
==Pointers==
| |||