Talk:Criticism of the C programming language

message: Some of the additions were more carping about C than factual.
For example, there are solid reasons why we don't want truncated source files to go undetected,
and no compelling reason I have ever heard to the contrary;
further, most well-defined programming languages have a similar requirement,
so even if you don't like the property it is not really a criticism of C.
This article was split off the main C programming language article for structural reasons,
not to provide a forum for airing grievances about C.
I made some changes to restore balance.
— DAGwyn 06:24, 1 September 2006 (UTC)
replies: text: If it often is a point of criticism, then it seems appropriate for this article, whether or not it is always justified.  Indeed, I could "rebut" several of the criticisms, but haven't tried to do so, because that would turn the article into a flame war. — DAGwyn 21:05, 27 October 2006 (UTC)
thread_title: Restoring Neutral Point Of View

message: Is there a specific reason behind this article's title? If not, I think a better name would be Criticism of C programming language. --Gray Porpoise 17:52, 4 September 2006 (UTC)
replies: text: It was spun off from the main article "C programming language".  As a subtopic the title seems okay to me. — DAGwyn 01:24, 5 September 2006 (UTC)
replies: text:  Note that it has now been renamed to "Criticism of C". — DAGwyn 19:16, 29 September 2006 (UTC)
replies: text:  Note that somebody has renamed it yet again, to "Criticism of the C programming language". — DAGwyn 20:37, 20 November 2006 (UTC)
thread_title:  Move? 

message: * Reaching the end of a function without finding a return statement, when the return value is used.
Almost any compiler less than 15 years old produces an error in this case, or at least a warning.
* Reading the value of a variable before writing to it.
Again, most compilers raise warnings/errors about this as well.
If we're criticizing "ancient C" I suppose it's OK to leave those items in, but they are obsolete. --Shyland 11:00, 25 February 2007 (UTC)
replies: text: Actually there are zillions of possible instances of undefined behavior, but the article tries to pick out several that cannot be correctly diagnosed at compile time.  In fact the C standard requires conforming implementations to accept programs that potentially trigger the above cases of undefined behavior, because in general it cannot determine at compile time whether u.b. will occur at run time or not (it depends on the dynamic flow of control, which can depend on the values of variables, and on linkage to other separately compiled modules that in general are not known when compiling the current translation unit). — DAGwyn 04:29, 26 February 2007 (UTC)
thread_title:  Undefined Behaviour section 

message: It is said in this article that C doesn't support automatic memory management. However, such thing is not language-dependent. It is feature of supplied libraries and system environment. Now we see that .NET Framework uses automatic memory management, and native Win32 platform doesn't do it, and actually all Win32-targeted languages have not automatic memory management, but all .NET-based ones have it. Actually memory allocation and releasing is call to functions, and how these functions are implemented is not language-dependent. If we have automatic memory management library, we can call it even from Assembler.
:: I'd say the most important part of automatic memory management is that you shouldn't have to call any kind of delete / free function. While libraries that let you do that in C exist, they don't (and couldn't) work correctly on all C programs if you replace all calls to "malloc" with a memory manager. In languages like C# and in particular Java, you have to use the memory manager, and the standard is designed to make one easy to implement. —The preceding unsigned comment was added by Mrjeff (talk • contribs) 23:21, 5 March 2007 (UTC)
replies: text: Yes, the model the criticism has in mind is garbage collection, where no-longer-referenced variables are reclaimed by the system, not requiring any explicit programmer action (such as calling free/delete).  C does have automatic variables, but only within the stack-oriented procedure call hierarchy. — DAGwyn 23:45, 5 March 2007 (UTC)

text: Err... what? It's the exact opposite. Criticism is neutral and flaws is not. Dlong 01:25, 17 June 2007 (UTC)
thread_title:  Automatic memory management 

message: OK, I've reworded this again:
Many operations in C that have undefined behavior are not required to be diagnosed at compile time. In the case of C, "undefined behavior" means that the exact behavior which arises is not specified by the standard, and exactly what will happen does not have to be documented by the C implementation.
If this isn't of a suitable standard would someone explain what the phrase '"illegal" operations' is supposed to mean?
Secondly, the comment in brackets about array indexing is hardly relevant, unless someone is going to add some criticism of array indexing to this article. I believe it should be removed. Also, I still believe the sentence about heap memory management to be too long. 62.212.118.231 19:47, 17 July 2007 (UTC)
replies: text: It's getting better.  I'll work on the memory allocation part.  One issue is that the problem is not just with the users of the accidentally-shared chunk; also corruption of the bookkeeping used by the allocator itself can (and often does) occur, which can lead to clobbering of "random" unrelated data when pointers are overwritten, etc. — DAGwyn 22:05, 23 July 2007 (UTC)
thread_title: Largely wrong and ungrammatical edits

message: In this section is the statement:
"There are dialects of C, such as Objective-C and Cyclone...".
I don't think that Objective C is a dialect of C. Rather Objective C and C++ are supersets of C which are implemented as pre-processors. In other words they are extensions that add object oriented functionality to C but don't change the language. This is why you can always use C when programming with them. Is this correct?Senor Cuete (talk) 03:52, 16 May 2008 (UTC)
replies: text: I don't really know about Objective C, but C++ is not implemented as a preprocessor nowadays, and has advanced far being just adding object orientation. There is no particular reason why a C++ compiler would have to also support C. Eric119 (talk) 04:10, 16 May 2008 (UTC)
replies: text: "Derivatives" might be better than "dialects", but I don't think it's wrong enough to need correction.  By the way, some valid C code is not valid C++ code, and some is valid but is given different sematics by the two languages.  C++ is not a strict superset of C. — DAGwyn (talk) 20:09, 16 May 2008 (UTC)
thread_title:  Tools for mitigating issues with C