Talk:C (programming language)

From Wikipedia, the free encyclopedia

	C (programming language) is a former featured article. Please see the links under Article Milestones below for its original nomination page (for older articles, check the nomination archive) and why it was removed.
Article Milestones Date Process Result March 15, 2004 Featured article candidate Promoted July 25, 2006 Featured article review Demoted September 9, 2006 Good article nominee Not listed Current Status: Former featured article

Archives Archive 1

Contents 1 C: High, middle, or low-level language 2 Confusing link 3 Initialization of static variables 4 D 5 C# 6 Object code and linking 7 Jokes 8 remove links 9 External links arrangement 10 Article too long 11 Libraries Section 12 VB equivalent 13 Featured article candidate: Forth 14 Featured article review 15 System Programming Citation needed? 16 "Discarded" Operators? 17 The malloc() example 18 K&R vs ANSI/ISO parameter declarations 19 Help the newbie 20 Guidelines for Citations 21 Citations 22 Reasons for not promoting 23 Forth is lower than c 24 Requested move 24.1 Voting 24.2 Discussion 24.2.1 Response to DNewhall's comment 24.2.2 Repsonse to Deco's comment 24.2.3 Simpler disambiguation 24.2.4 Pages like C programming language, criticism 25 Burroughs MCP use of ALGOL? 26 Failed GA nomination 27 Hello, world example 28 C 29 C++ superset of C 30 A small set (around 30) of reserved keywords 31 relatively simple compiler 32 Negativity of this article 33 Binary operator associativity

[edit] C: High, middle, or low-level language

Okay, I can see we're seting up for a revert war here with the question of whether C is a high-level language, low-level language, or something in-between.

Personally, I've always thought of C as one step above assembler, so it's a pretty low-level language to me. (It's got no inherent matrix operations, no string operations, no garbage collection, etc. You get to manage memory all by your lonesome self. Pointers are a nearly-direct representation of what PDP-11s and VAX computers do in single machine-language instructions.) And other text in the article supports this assertion. But I'd like to hear what others have to say before changing this again.

Atlant 12:06, 17 May 2005 (UTC)

I want to say "medium"; "low-level" as I've heard it used has a strong connotation of "assembler or machine language", but C is certainly the lowest thing that has been called a high-level language. DanielCristofani 14:10, 17 May 2005 (UTC)

Well, compared to languages that are being designed today, C is relatively low-level, but I think the historical precedent has been to describe C as high-level. In contrast, languages like Python are often called "very-high level languages". In any case I don't think we should use the term "medium-level language", as that is not at all standard usage (googling for "high-level language C" yields more than 5.5 million hits; googling for "medium-level language C" yields fewer than than 35,000). Therefore, given the choice between high- and low-level, I think HLL is a better description of C. Neilc 03:39, 27 May 2005 (UTC)

What would happen if we didn't use any of these phrases (at least prominently near the start of the article)? If they don't have clear, agreed-upon meanings even among people knowledgeable about programming languages, I doubt they're much use to the less-informed readers the article is written for. I'm going to remove the phrase and see if anyone objects. DanielCristofani 04:47, 27 May 2005 (UTC)

A link to medium-level programming language somewhere in the article is necessary, as it describes many important characteristics of C and other C-level languages. It doesn't have to be on the top. The terms high-level and low-level are historically pretty well defined (at least better than some like "object-oriented" or "structured"), and C is a canonical example of neither, but a borderline case. Hence the invention of term "medium-level" (or "portable assembler" / "high-level assembler" etc.). And I didn't know about the 17 May revert when I did the change, no revertwarish intentions here, just a coincidence. Taw 11:55, 27 May 2005 (UTC)

I've just made "low level" and "medium level", down in the first paragraph of "Overview", into links to the appropriate articles. DanielCristofani 03:50, 28 May 2005 (UTC)

C is not "typically" called a "low level language". It is at least a medium-level language (I would still argue it is a high-level language according to historical precedent). Neilc 05:24, 28 May 2005 (UTC)

I've tried to rephrase it; it's a little awkward and maybe the paragraph now needs rewriting but it should probably say the same things it now says and should include all three links... DanielCristofani 10:19, 28 May 2005 (UTC)

I think that "levels" in this usage is relative to implementation (with "machine language" being the lowest possible level in any case). For example, if an application is written in C and then directly translated into machine language, then C is the higher level language in this implementation; but if an interpreter for BASIC was written in C, C would be the middle level. I think that defining levels may be meaningless without a context. Mal7798 05:13, 03 June 2006 (UTC)

I certainly wouldn't object to the lede not trying to characterize the "level" of C.

Atlant 11:35, 27 May 2005 (UTC)

The fact is, these "levels" are too ill-defined and inconsistent in their usage to characterize the level of nearly any language, especially one lying near the boundary like C. Better might be to give comparisons; I think we can all agree it's higher-level than assembly, but lower-level than Ada, Smalltalk, Java, or Haskell. Or we might just say, "some call it X because Y" for each one — just don't go on about it in an inappropriate place like the intro paragraph. Deco 09:54, 28 May 2005 (UTC)

It's certainly the case that C is a HLL in the mainstream sense of that term, namely "something significantly higher and significantly different from, but that typically compiles down to, assembler." And it's equally certain that C is very low-level, as high-level languages go. These points are very well worth mentioning, as is a third: that referring to C as "high level assembly" is sometimes done fondly and sometimes pejoritavely (that is, critics accuse C in this way, but adherents love the language for it).
But the term "medium level" is, I agree, pretty meaningless. Steve Summit 05:34, 13 July 2005 (UTC)

As to the question of C's "level", I agree that catagorizing the language this way is mostly without warrant. C is, in nearly ever sense of the word, a beginner's language. I believe it to be realtively simple, and only a step above the beloved BASIC dialects. In fact, my first language was C and I believe it to be a valuable learning tool. For this reason, if find it hard to describe C as a "high level" language, yet at the same time I remain partial to it and hope it remains in close memory.- Shoe1127 22:08, 19 May 2006 (UTC)

Shoe1127, "high-level" doesn't usually mean that a language is difficult, it means that the languge abstracts away from hardware details. Thus, it is possible for a beginner's language to also be high level -- in fact, BASIC is in a high-level language. Regarding the question of whether C is high-level or low-level or neither, I don't really have anything to add... Cadr 22:52, 19 May 2006 (UTC)

I would say c is a medium low level language. I program several languagess and this is what i think thanks Rekh 19:08, 30 May 2006 (UTC)

The terms "high-level" and "low-level" refer to how similar the langauge is to the hardware. Since C is portable, technically it would have different "levels" in comparison with different architectures. However, since most hardware is very similar, the "level" of C can be said to be about the same for every architecture.

Saying this, it should be noted that the terms "high-level" and "low-level" are NOT precise, exact, OR well defined. Parts of C are high-level, and parts are low-level. Saying that the language is "somewhere between" is NOT accurate, nor does it give a good picture of what C is - which is a mix between low level and high level syntax.

I disagree however that the "level" of a language is a bad way to categorize - but if we do categorize C this way, it should be CLEAR what we mean by it. Fresheneesz 00:50, 3 June 2006 (UTC)

From The C Programming Language by K&R, first edition (I'm old school), page 1:

"C is a relatively 'low level' language."

From Introduction to Computing Systems: From Bits & Gates to C and Beyond by Yale Patt and Sanjay Patel, second edition, pages 293-294:

"C was developed for use in writing compilers and operating systems, and for this reason the language has a low-level bent to it. The language allows the programmer to manipulate data items at a very low level yet still provides the expressiveness and convenience of a high-level language."

I think it's best to say that C is a relatively low-level language, as compared to high-level languages. I wouldn't call it medium-level, since there really isn't such a thing. Low-level implies the language keeps the programmer in touch with the machine, high-level implies otherwise. 70.106.101.119 19:25, 19 June 2006 (UTC)

Could we just say it's a high-level language as compared to assembly language but low-level as compared to other high-level languages? If a bunch of people knowledgable about C can't make up their minds, it's evident that there's probably not one right answer. Deco 21:38, 19 June 2006 (UTC)

I have always considered it a fairly low-level language. The definition I'm familiar with for a low-level language is that the number of machine language statements generated tends to be less than the same program written in a high-level language. The fact that K&R also considers it a relatively low-level language, I would vote for "relatively low-level language". wrp103 (Bill Pringle) 21:54, 19 June 2006 (UTC)

Hmm, that's a weird definition. Let me throw in a vote for (somewhat) "High Level". C has complex control structures (do, while, for), functions, and a real and powerful type system. At the time it was created, it was high level, about on par with Pascal or Modula 2. Low-level languages are languages that are specific to a processor, high-level languages abstract these details away... --Stephan Schulz 22:07, 19 June 2006 (UTC)

It is a low level language if you look at c key words it is very low there are 33 key words. Everything else is additional functions not neccessary to use. Rekh 18:23, 21 June 2006 (UTC)

I'm kind of with you on that, and everyone else seems to have missed the point :) The problem is a fundemental problem of definition, which this page hasn't addressed yet. The 33 key words define a low level (3G, procedural) language: there aren't even input and output operators. On the other hand, standard C (which includes the standard C libraries), is an ordinary (3G, procedural) language. 218.214.148.10 02:39, 6 November 2006 (UTC)

The 'closeness' to asm or machine code has become a bit of a red herring partly because most people have never examined the machine code generated by Pascal or Fortran compilers, so that's worth clearing up: For most of their lives, Pascal and Fortran compilers generated smaller, faster, tighter code than C compilers, and there was generally a one-to-one correspondance between lines of code and assembler constucts in all three languages. The smaller faster tighter code resulted from better optimisation (tied to the simpler syntax), and better integration of the 'library' functions, not because i++ compiled differently than i=i+1.

On the other hand, sprintf is a high level construct, and that's why C, not Pascal or Fortran, eventually replaced asm as the language of choice for writing Windows Device Drivers. The high level constructs in C are parts of the library that can, with care, be re-written or excluded. Note that it took a while though: Windows NT was written in C, but the Windows NT device drivers were written in asm, because in C it was difficult to get the kind of smaller tighter faster code required. 218.214.148.10 02:39, 6 November 2006 (UTC)

That's mainly because the x86 architecture doesn't provide good support for HLLs including C. Unix device drivers were all written in C on the PDP-11 and VAX, even the interrupt-handling code (except for a small veneer to save "scratch" registers and map into the C functioon interface). On some processors such as M*CORE, there is such a close match that even the interrupt-handler veneer isn't needed. PDP-11 C programmers quickly learned how to code so that they would get the desired object code, e.g. do...while(--i) to get a SOB instruction. The optimizer underwent continual improvements, but for a long time you'd see micromanaged source code like this. Efficiency really mattered on small, slow machines. DAGwyn 21:04, 7 November 2006 (UTC)

Yeah, my final vote is that C is a relatively low-level programming language. If that's good enough for K&R, that's good enough for me. 70.17.41.123 21:02, 21 June 2006 (UTC)

A lot of the confusion comes from a seemingly small distinction. Are "low level" and "high level" two distinct categories of languages, or are they purely relative terms like "tall" and "short"?

Both uses have a long history. When the terms are used to refer to distinct categories, "low level language" means machine language or assembly language--these are processor-specific, and assembly is almost isomorphic to machine language. A "high level language" is then anything that needs a compiler or an interpreter. (If people were going to draw a crisp line, it makes sense that it was placed there, because there is a bit of a gap between assembly and (say) FORTRAN and then a smooth-ish gradation from FORTRAN up through more and more abstract and featureful languages. Also, when the line was drawn, other languages were not vastly more featureful than C, and it was still common for people to write programs in assembly language.) In short, when "low-level" and "high-level" are used as names of discrete categories, C is definitely a "high-level language".

On the other hand, when the terms are used in a purely relative way, C is plainly at a lower level than most other computer languages, and especially it is at a lower level than most other computer languages people write programs in, since assembly-language coding has lost popularity. (Likewise FORTRAN etc.) So it is entirely correct to say that "C is a relatively low-level programming language" or "compared with more recent languages, C is a low-level language". Even "C is a very low-level language" would be better than "C is a low-level language", because the word "very" would make it clear that the phrase was being used as a comparative, whereas in isolation it looks like a classification.

But there are more modern languages that are assembly languages, so "compared with more recent languages" is going down the wrong track. — DAGwyn 09:43, 2 September 2006 (UTC)

In short, yes, "C is a relatively low-level programming language" and "C is a high-level programming language" mean subtly different things and they are both unimpeachably correct. DanielCristofani 21:37, 21 June 2006 (UTC)

One way of rolling both aspects into the same sentence is to say "C is relatively low level as high-level languages go." —Steve Summit (talk) 14:42, 23 June 2006 (UTC)

The categories are sloppy to start with, and there isn't a well-ordering of "levels" for PLs. C is definitely a low-level HLL. Unless something crucially depended on the category, which it doesn't, "relatively low-level" conveys enough of the right flavor: not the lowest level, but also not very far from it. — DAGwyn 09:43, 2 September 2006 (UTC)

[edit] Confusing link

i´ve deleted the link because this is not suppose to promote paying books, nevertheless its quality. if you want to promote a book try other place! or even other sectionin wiki.
[preceding unsigned comment added 4 February 2006 at 18:54 by 62.169.90.135 (Talk | contribs)]

The deleted link was to the book C Unleashed by Heathfield et al. External links to reference materials should be included or deleted based on their relevance and notability, not on their free/paid status. (We've got several other printed, purchasable books listed, all relevant and notable.)

I'm not going to restore the link myself, because I'm one of its contributors and therefore not unbiased, but if anyone else would like to, feel free. (The book's notability is somewhat enhanced in that many of its contributors were comp.lang.c regulars.) Steve Summit (talk) 23:36, 5 February 2006 (UTC)

Agreed. I restored the link to the book. In my opinion, it's not appropriate for an encyclopaedia not to list notable purchasable material solely due to the fact that it's not free. Denis Kasak 15:16, 29 March 2006 (UTC)

[edit] Initialization of static variables

Hi, I recently came across in C that we cannot call functions while initializing static variables in C, why is it so?

int my_function(void);

   int main()
{
   static int p = my_function();
}

Thanks

Because all static data is required to be initialized prior to program startup, and parts of the program cannot be run before it starts. Deco 05:52, 21 February 2006 (UTC)

Well, then how is the same possible in C++, and by the way do you mean to say that memory is allocated for static variables well before the program starts.

Well, C++ is a different language! It's got mechanisms that let initialization code run before main() is called. C doesn't do that. But yes, it's correct to imagine that the memory for static variables is allocated and initialized before main is called. --Steve Summit (talk) 15:55, 21 February 2006 (UTC)

Yeah, C++ needs this to enable constructors of objects of global lifetime to run properly. Deco 18:04, 21 February 2006 (UTC)

[edit] D

Is the paragraph on the D language really necessary in the C article? It seems like a 'See also' link would be enough. --ozzmosis 12:08, 10 March 2006 (UTC)

It's in the right place. Since C has spawned so many imitators and successors, a "Related/Successor languages" section is appropriate. The paragraph on D someone just added is appropriately brief. The C++ discussion just above should probably be condensed. It would probably be worth adding brief paragraphs on other notable successor languages, including Java and maybe Perl and JavaScript. —Steve Summit (talk) 15:10, 10 March 2006 (UTC)

But Objective-C is much closer related to C than D (or even C++) is, still it is not mentioned here... —The preceding unsigned comment was added by 62.178.213.223 (talk • contribs) 23:31, 18 March 2006 (UTC)

Sofixit! :-) —Steve Summit (talk) 01:48, 19 March 2006 (UTC)

agreed - the D paragraph explicitly says it is making a break from C - so why include it here? There are plenty of languages that are just as close to C or closer than D. The paragraph should be removed.

I don't agree. It's useful to have brief mentions of the languages closely related to C. I would include: C++, Objective C, D, Java and maybe C#. The discussion of C++ is too long. It should be about the length of the paragraph on D, with a pointer to the full article. I don't think that "making a clean break" makes a language necessarily more distant. Even though C++ attempts to maintain backwards compatibility with C, in other ways it is more distant from C than is D. In particular, I would say that the lack of multiple inheritance makes D in a significant respect closer to C than C++ is.

The point is that there is a small group of languages conceived by their creators as improvements to C (as opposed to languages of a quite different type), and it is useful mention these and give brief summaries of their relationship to C in the C article. The alternative of just listing pointers to the articles about them is inferior in that those articles will not in general focus on the differences from C. We shouldn't force the person who is mainly interested in C and just wants a little bit of context to have to work through those other articles and figure out the differences himself or herself.Bill 21:02, 9 May 2006 (UTC)

Then I'd list Java, C++, Objective-C, C#, Ch, Cyclone, C-- (there are I think several of these) and D (at least). It's misleading to just put C++ and D.

Indeed, if you look at my first paragraph you'll see that I suggested a longer list.Bill 08:11, 11 May 2006 (UTC)

It all boils down to what "related languages" mean. C++ is given, because it is a direct successor to C basically implementing the entire feature-set, and so is Objective-C, which should have an entry. Unless the rubric read "other curly-bracket languages" (or "languages vaguley remninescent of C in some ways") D shouldn't be featured any more than Java. Especially since the article says that it breaks cleanly with C, which basically only makes it nothing but a curly-bracket language with only superficial similarities with C, just as Java. Mikademus 08:12, 7 July 2006 (UTC)

Edit: I added a section about Onjective-C. Since both C++ and ObjC are supersets of C it makes the D entry even more out of place. Mikademus 08:23, 7 July 2006 (UTC)

Perl is more a successor to AWK than to C, don't you think?Bill 03:15, 19 April 2006 (UTC)

[edit] C#

Since some feel that programmers are not encouraged to understand the workings behind C# and the way it handles possible "dangerous" computer tasks, they are expected to trust that C# simply works. Some programmers believe that it is not anywhere nearly as stable as C or C++. C# is often compared and contrasted with C and C++. C# runs on the .NET Framework and was developed by Microsoft.

I don't have any bias towards Microsoft or any other software development company, but I've never heard of C#'s "stability" being an issue. Since C# is merely a language, any comments about stability don't make any sense (unless you decide to confuse C# with the .NET Framework, which is the underlying virtual machine). Since the .NET Framework itself has gathered a good reputation for its own speed and stability, I'm not sure where the contributor was trying to go with this. You could probably make a pretty good argument that managed code is actually more stable than native C, especially with garbage collection and the lack of unsafe pointers.

Either way, though, "some programmers" and "some feel" are a great example of weasel words, which I think should be avoided. What are your thoughts? Alexthe5th 11:16, 12 April 2006 (UTC)

I don't see why we need to discuss C# at all: although it happens to have "C" in its name, it is not all that closely related to C (no more closely related to C than Java is, for example). Since the text was pretty poorly written (I agree with the gist of Alexthe5th's comments), I just removed this section. A section on Objective C would be reasonable, as it is closely related to C -- but I think C# is sufficiently far from C it doesn't deserve a whole subsection. Neilc 03:32, 19 April 2006 (UTC)

I agree. C# procures C's syntax and good name to draw attention, not unlike C++ or Java before it, but its semantics are distinctly dissimilar. Deco 21:20, 17 June 2006 (UTC)

[edit] Object code and linking

This article could do with a cursory reference to other pages describing object code and linking. I think the "Hello World" example gives the misleading impression to a newcomer that the printf function's implementation is contained in stdio.h, whereas in fact all that is there is a declaration of the function, that is linked later on.

What's not obvious to a C newcomer is the "compiler" is typically a front end that includes the preprocessor, source to object code compiler, and linker, and that a link to the standard library ( eg: libc.a (Unix), libc.lib (Microsoft) ) is automatically implied.

This concept confused me for a while when I first learned C on a DOS platform, as I assumed that somewhere inside the standard library there must be C code that writes characters to the display, whereas in fact that was written in 8086 assembler calling DOS INT 21, using the correct calling convention, and linked in.

I don't think there needs to be much in-depth discussion on the main page as it sets better on another page specifically covering linking architecture, but a cross reference would be useful.

Thoughts?

--Ritchie333 12:24, 20 April 2006 (UTC)

Good idea. Such an article could/should be written generically, with specific details on specific (i.e. C) languages. Wouter Lievens 12:55, 20 April 2006 (UTC)

Sounds good to me. wrp103 (Bill Pringle) 14:19, 20 April 2006 (UTC)

[edit] Jokes

Blatant jokes should not be placed in serious articles in Wikipedia, regardless of whether the joke is "standard" or not. Wikipedia should aim for a semblance of professionalism, and jokes do nothing to contribute to this. Dysprosia 11:45, 11 May 2006 (UTC)

Agreed. --ozzmosis 12:04, 11 May 2006 (UTC)

Disagree. Several articles that I watch have well-crafted bits of humour and levity in them. As long as the humour is either obvious or identified as such, there's nothing that makes that "unencyclopaedic" or even "unprofessional".

Atlant 13:03, 11 May 2006 (UTC)

If we are taking a vote, I don't see any reason for a section on "Jokes about C". Also, I've been programming in C for over 25 years, and I've never heard any of those jokes. The only one that I would consider "standard" would be "a high level assembly language". wrp103 (Bill Pringle) 00:03, 12 May 2006 (UTC)

[edit] remove links

Can I know why a simple tutorial would be removed ? http://www.alnaja7.org/Programmer/101/itcs_101.htm Alhoori 21:48, 20 May 2006 (UTC)

The issue has already been addressed on your talk page. OhNoitsJamie^Talk 22:03, 20 May 2006 (UTC)

You didn't answer ! Alhoori 00:10, 21 May 2006 (UTC)

These are better than http://www.alnaja7.org/Programmer/101/itcs_101.htm ?

Not to mention that the tutorial is very badly written, making dangerous, unportable and, what is most important, unnecessary assumptions about many things. I won't even go into the dreadful and overzealous colourisation. All in all, it would do more damage than good to a beginner in C. Denis Kasak 14:33, 6 June 2006 (UTC)

• Essential C — Short C guide, great for programmers new to C.
• Everything you need to know about pointers in C

[edit] External links arrangement

I am new to C, and I have come here to see this article just in order to learn C. I browsed trough the totorials, and the one that was the easiest to understand (and the most expanded too) was http://www.alnaja7.org/Programmer/101/itcs_101.htm, who appears the last and is not one of the 'recommended' totorials. (by recommended I mean that they are the last and they dont have any notes on them that say they are easy and good.) Well, what I want to say is that I think that section should be rearranged. (Sorry if I have any mistakes in my English.) —The preceding unsigned comment was added by Tapuzi (talk • contribs) .

The easiest way to fix this is for you to move the links up and/or add some comments about the site / tutorials. Different people learn different ways, and what is a great tutorial for you might not be so for someone else (and vice-versa), so a brief description of the tutorials would be a help. Also, your english was just fine. wrp103 (Bill Pringle) 13:35, 25 May 2006 (UTC)

It would probably be more beneficial to you, as a beginner, to stop reading such random tutorials from the 'net because there tends to be a high level of inaccuracy and erroneous information inside. The one you mention is particularly badly written. Instead, go to the library and grab a good book. There are a couple good recommendations in the article itself. Denis Kasak 14:45, 6 June 2006 (UTC)

Thanks for the advice. I borrowed a book from a friend which was pretty good, and now I can say that I know C. But from looking back to this toturial - I think that it doesn't miss any important point and also that its pretty much accurate. I admit that the book I read was hard, so I had to use some of my knowledge from this (http://www.alnaja7.org/Programmer/101/itcs_101.htm) tutorial in order to understand a bit of the book. So, in my opinion, this tutorial was and still is a good tutorial, and i think it should take place in this article. Tapuzi 11:18, 13 July 2006 (UTC)

I deleted this link. The person who made this page keeps inserting links to his own webpages into many articles. I'm not a complete expert in C, but I am in C++ and found that his C++ tutorial is riddled with errors and is of a generally poor quality. Having a quick look at the C tutorial: The classic problem, the data types page implies the size of char, short, int, long, etc. are fixed by the standard. That is wrong. Also RAND_MAX doesn't have to be at least 32767. I didn't look very hard, thats just two common mistakes. I'm not saying it's a bad tutorial, just it's not the best the net has to offer, and I believe it's important to keep the number of tutorial links to a very small number (personally, I'm not entirely convinced they should be there at all... but that's another story). Mrjeff 12:24, 13 July 2006 (UTC)

I just wanted to add to my previous post, I don't want that post to sound too negative, I'm always glad to see new people getting involved in wikipedia. However, I think it's more useful to spend time improving articles than linking to other people's websites. Mrjeff 12:28, 13 July 2006 (UTC)

According to Section 7.20.2.1 of the ISO C Standard "The value of the RAND_MAX macro shall be at least 32767." Mickraus 15:46, 23 January 2007 (UTC)

[edit] Article too long

This article needs to be broken down into parts - it is much too long. For example, the hello world example is unnecessarily long, and I think I will move the step-by-step explanation of it to a new page (perhaps there can be a hello world page, with multiple languages' examples on it). I've archived most of the content that was on this talk page, so I hope that the article can once again be improved upon with coordination. Fresheneesz 00:54, 3 June 2006 (UTC)

I agree, and as for the Java article, the criticism section should be in a separate article, this article just linking to it and providing only a synthesis of common critics about the language. It now just confuses the reader. I also find rather comic than the C# article has no criticisms section at all !! Hervegirod 09:44, 11 June 2006 (UTC)

[edit] Libraries Section

I'm concerned about the new section for libraries that was recently added. To begin with, the description was wrong, but also I'm concerned that it will make an already too long article even longer, with minimal benefit for the main article on C. I would suggest that a new article be started for C programming libraries and a link included in the "See also" section. wrp103 (Bill Pringle) 13:16, 3 June 2006 (UTC)

[edit] VB equivalent

Does one interpret the following C construct:

for(i=0; i<end; i++) {
int c = array[i]+1-min;
count[c]++;

in Visual Basic as:

for i=0 to end-1
c = array(i) + (1 - mim)
count(c) = count(c) + 1
next i

...IMHO (Talk) 15:54, 3 June 2006 (UTC)

Yes, that looks like a fine translation. Deco 21:18, 17 June 2006 (UTC)

Except that 'min' should be used instead of 'mim' Mickraus 16:26, 24 January 2007 (UTC)

[edit] Featured article candidate: Forth

I have put Forth up as a featured article candidate. Please participate in discussing how it can be made to equal this article in quality. Ideogram 07:20, 4 June 2006 (UTC)

[edit] Featured article review

Can someone provide a link to the revision of the article that was featured, for comparison? (I know it's changed a lot since then, so I'd say some review is appropriate.) —Steve Summit (talk) 13:16, 23 June 2006 (UTC)

Actually, the main problem is lack of citations, for which standards have changed since the article was featured. Ideogram 17:17, 23 June 2006 (UTC)

[edit] System Programming Citation needed?

The assertion that C is the most common language for system programming was flagged as needing a citation. It seems so obvious to me, I'm not sure why anyone would think it needs a citation. Does anyone know another language that might be able to make that claim? wrp103 (Bill Pringle) 21:51, 11 July 2006 (UTC)

My guess would be that the only other contender (besides the debatably-separable C++) would be IBM System/360 through Z/OS Basic assembly language. I doubt there's another close contender, although X86 assembler must be right up there, at least if we're considering "programmed units sold".

Atlant 12:11, 12 July 2006 (UTC)

Indeed the original designers (K & R) developed C for the purpose of systems programming (Unix). Mainly for portability. The early C libraries were primarily system functions. —Pelladon 07:12, 4 August 2006 (UTC)

[edit] "Discarded" Operators?

"C ... was the language that orginally discarded well established operators such as and, or and = (for equality test)"

Is "discarded" the wrong verb? Is this referring only to the lexical tokens (operator symbols, not operators) used? Perhaps "replaced" would be better, and a mention of what replaced them: &&, ||, ==.

There could also be a clearer comment on why this relatively superficial syntactic issue is significant. Many successful recent languages have copied the syntax of C for logical expressions and assignment.

The meaning of this passage was not obvious to me at first reading, I am unsure if it is really about syntax and symbols. It will probably also be unclear to other (non-native-speaker English) readers, so it should be clarified one way or the other.

Fbkintanar 01:55, 26 July 2006 (UTC) Cebu City

I agree that the comment isn't that clear, especially since there were other languages that didn't use and and or as well (e.g., FORTRAN used .AND. and .OR.). What was significant, however, was the differentiation between equality and assignment, where C used the double equal sign to indicate equality, while many languages of the time didn't differentiate between the two uses. The other significant thing that C did was implement both logical and bitwise and and or operators. wrp103 (Bill Pringle) 03:09, 26 July 2006 (UTC)

[edit] The malloc() example

I took out the malloc() example again. It has a large number of problems, and is not really necessary anyways.

int *DynamicArray(int newSize)
{
  int *tbl;  /* will be a dynamic array */
  tbl = malloc(newSize * sizeof(int)); /* allocate memory */
  return tbl; /* tbl can be referenced like any array (e.g., tbl[i]) */
}

• While I personally like CamelCase for some functions, this is unidiomatic for C.
• The parameter should be a size_t for any function of this kind.
• No check for NULL. Idiomatic C would be to directly write array = malloc(newSize * sizeof(int));.
• Since tbl can be NULL, the last comment is actually wrong.

--Stephan Schulz 18:04, 26 July 2006 (UTC)

Yeah, I was going to write only the first two lines, but got carried away and decided to write it as a function. I don't like CamelCase either, but the earlier examples on prototypes used it. (I try to follow whatever stylistic standards already exist.)

I would like to see the code someplace, since there are few places that explain how to create dynamic arrays in C, and many of the text books I've had to use often claim it can't be done, soI have to keep correcting students' papers.

BTW - it doesn't have to check for NULL, since the caller should test for NULL to determine if the function worked. You are right about size_t, I keep forgetting all the new-fangled stuff they've added to C. ;^) wrp103 (Bill Pringle) 19:52, 26 July 2006 (UTC)

Sure, but if you do not check for NULL, the function is kinda pointless ;-). And you cannot reference tbl[10] if tbl is NULL. If you want to preserve it, I would suggest to move a cleaned-up version into malloc(). It does not really create a dynamic array anyways, just something that looks a lot like one (but then the newfangled C standard now allows real dynamic arrays in local scopes ;-). --Stephan Schulz 20:23, 26 July 2006 (UTC)

P.S.: Reading comp.lang.c and comp.std.c is an excellent way to be exposed to any new features and any amount of language lawyering you can wish for. In fact, it's a bit like drinking from a firehose at first ;-).

Well, if the function checks for NULL, what would it do? You certainly don't want to terminate the program just because the system is low on memory. Whoever calls a function that returns a pointer should always check for NULL, so the only reason you need to check for NULL is if you are going to dereference the pointer. I have a friend who maintains it doesn't make sense to check for NULL, since it indicates the program is already in trouble, and will probably crash shortly anyway. ;^)

I know about all the new-fangled stuff; I just choose not to bother with them, unless I need to. ;^) Of course, several compiler vendors have made the same decision. ;^)

The fact that I had it in malloc() and it was removed suggests it wouldn't last there, either. Oh, well, its in my lecture notes. wrp103 (Bill Pringle) 21:19, 26 July 2006 (UTC)

[edit] K&R vs ANSI/ISO parameter declarations

Hi,

the article states that the way K&R declared parameters and how ISO/ANSI do it is semantically equivalent. This is not quite true. While with the ANSI/ISO way the parameters are indeed passed as the types specified, in the K&R way the parameters are passed as ints and then converted to the types specified. This is required to have a unique way of passing parameters in assembly when there is no declaration. Remeber, in B everything was int. This gets important at those points where functions are called without the declaration of the function, essentially foobaring up everything. —The preceding unsigned comment was added by 84.176.241.74 (talk • contribs) 12:52, 20 December 2006.

Actually when a prototype is not in scope the parameters are passed as promoted types, which include signed or unsigned int, signed or unsigned long int, (for C99 also signed or unsigned long long int), double, (for C89 also long double), structure, union, or a variety of (unaltered) pointer types. It doesn't make sense for the Wikipedia article to try to explain every detail, but if what it now has is badly misleading then it should be fixed. Perhaps the two ways are "semantically similar, although for Standard C argument types are converted to match the prototype while without a prototype in scope argument types may be widened (to at least int or double)." — DAGwyn 05:58, 21 December 2006 (UTC)

[edit] Help the newbie

I found this on Wikibooks.

int dividend = 50;
int divisor = 0;
int quotient;

if(divisor == 0) {
    // Handle the error here...
}

quotient = (dividend/divisor);

  // Handle the error here...

Handle the error with what code? Please help me. Thank you. --193.77.22.121 16:43, 27 July 2006 (UTC)

fprintf(stderr, "Division by zero attemted, report for termination\n");
exit(EXIT_FAILURE);

...or in other words, it depends on your application anf what you want to do with this code. --Stephan Schulz 16:48, 27 July 2006 (UTC)

[edit] Guidelines for Citations

What are the guidelines of when citations are required? The number of citations requested for this article seem silly to me, especially to those of us who have been working with C for a long time. For example, I've been using the term "portable assembly" for many years. Can I cite myself then? The comment about being available for a wide range of platforms is another one, and especially "probably more than any other language in existence". (Why do we need a citation for a "probably"?) Can somebody name another possible candidate for that statement? How many platforms are there that don't support C? I'm all for documenting sources, but this seems a bit much. I'm surprised somebody hasn't flagged the opening sentence as needing a citation. wrp103 (Bill Pringle) 16:06, 29 July 2006 (UTC)

 :-O You don't understand citations at all ! Please read the introductions of Wikipedia:Verifiability, Wikipedia:No original research, ((Wikipedia:Neutral point of view)), Wikipedia:Avoid weasel words and Scientific_method#Elements_of_scientific_method. Concerning your points: the term "portable assembly" is incorrect. The correct term is "mashed potatoes". I've been using it to refer to the programming language for many years, and all my friends use it too. Even my uncle has used the term before I was born to refer to C. Can I change it in the article and cite myself ? Also, the probability that C is more widely used is only 16,7%, as a Tibetan monk told me when I travelled to East Mongolia. So it's not that probable. The other candidate for that statement is χπτο, a language created by me, of course. Every country I go they are all using this language. The probability is around 65%, much higher than C, as my uncle told me. I'll cite a few platforms that don't run C. They are all Russian, so I don't know if you have used them:

• ИЕИИОНКЛИДОДКПЕОИКЙЖНЗЙЛДПЖЛДЖТЙЗЗЕСИЛКМТМЕРИЖТМДЙ
• ЖЖДЛЕДПЗЛПЙСМДЕНТРМРРЛРСРЕЛПЕДМИЖМЗОДТСТЗИРПИЙСОЖК
• ТДКПЙОИЙККРЛЖКЛЙЕМРТЛДОЙЗЛОЕНЙДНЙСРЖМЖЛТМПСОЖКЛЗКП
• ОСЗЙОЛИКДТЗЛДДЙРЖСТЖЙЛСЗНЕЕНИЛЙТКЕРММЕКДЛНМЛНЙЙРИИ
• КНИИИЙЙККЖСРМПСЙЙСТПЙККЙТДППИЛДОЕПДЙНРЗДКЖИДЙЖРОЛЗ
• ТЙЖЙОЕРСИНЙПИКМПИНЕЛНЛЕТТЛМИНМТМСЕЙДНОТСИИОМЗОРТИС
• ССРДИИТСММСЛНПЕТЗОНЖНСТИТЖТПМОЕКМССЙЖРОЖСМЖЛПЗСТЙМ
• ЖТСМОИЖЕЛОПМЕРТДЖМИРЗЖЙЙНЕДДЛЙМЕРСНЛОПНЖСРЗЛННТПНЗ
• ДРСЙНТСНТСЛТТИСНЗМРИЖЗЖЙОЗКНЛЕИЛСЖЙДЖОЕЕММЕМИКНМКС
• РДЕТСЗЗИИЖЙННПЗТПРЖИТОСЛОНЙИЖЗОДЗПКЕЛЕКПЗЗРЙТЕПЖСС
• ТИНИЗПСММЕПЗМЛККМСМКОЗОЛМЕДЙПТЗООИТТМРЛЕЙПИСЗОРЗЕЙ
• ОЗМЙЖНКЗТЖННИИКЗОТМОЛСКПИЕСЕИКСТНСПРТЗДСРЕДНРСРМИР
• ЗПЗЕТЛЖРДСИЙСЙОНЖОИНДНОДЗДЙЛМНЙПРМРПЛКНТИЙПНОКПЙЕЛ
• КЖЕННПНДПЖЕЕЙТЕНЖДДПКПМЖКПМЖМЖЕТИОМЙКНРЖЗТОМЙЗЖЛЗН
• ПНКПЗИТРСЛТТТОНТДМНСЖРИЙКЕМДДИЖПЙМДНИТСЖЛИМКТЗЙКЗК
• (...)

As you can see, there are thousands of architectures that don't support C. --hdante 16:18, 31 July 2006 (UTC)

Glad to see you have a sense of humor. Hopefully, somebody will answer my question.

Actually, "portable assembly" is my typo. The term I have been using is "high level assembly language," which pretty much conveys the same meaning. I recall making that comment to Kernighan once, and he didn't contradict me, so I tend to think it is more accurate than "mashed potatoes".  ;^)

Just having a citation isn't always enough, BTW. I've been stuck with several text books that made incorrect statements about C, so citing them as a reference would be misleading. As for NPOV, there are lots of topics where you can cite an article that is very POV. It is also easy to get citations that contradict each other as well. IMHO, the best way to guard against POV is many pairs of eyes and intelligent discussions. wrp103 (Bill Pringle) 17:02, 31 July 2006 (UTC)

No, the Wikipedia standard is "Verifiability, not truth". If all the sources say that the world is flat, then Wikipedia must say that the world is flat, because asserting based on our knowledge that the world is round is Original Research. The only way to draw the conclusion that a citation is incorrect is to do your own Original Research, which is not allowed. If citations contradict each other, we include both sides. NPOV doesn't mean no point of view, it means we report the major points of view without judging which is correct. --Ideogram 20:49, 31 July 2006 (UTC)

[edit] Citations

I'm all for citing sources when appropriate, but I don't see the need to cite a source to support a claim like "the [C] language has therefore become available on a very wide range of platforms." By any reasonable definition, that is simply true. I also fail to see how it is POV, as Hdante claims in the revision history. Finally, if you insist on citing sources for border-line situations like these, I think you ought to just go ahead and cite the sources you think would be appropriate, not just lazily scatter {{fact}} tags throughout the article. {{fact}} is fine when the claim is begging for a citation, but it just clutters up the article in this case, IMHO. --Neilc 22:54, 30 July 2006 (UTC)

I agree with both Wrp103 and Neilc: system developers and implementors know well that C is the common language most likely available for new hardware or a new processor architecture. There is no need to cite this assertion—though one would be welcome. Likewise, there is no need to support the fact that K&R is the most basic language subset: This is self evident, given C's undisputed history. As for the "ardousness" of the C89 standardization, this is more worthy of a citation (and probably easier to find) than the others but, come on, it was a six year effort with plenty of cooks in the kitchen.... —EncMstr 23:31, 30 July 2006 (UTC)

The relevant sentences are:

• Because of simplicity, the language has therefore become available on a very wide range of platforms - I don't agree that simplicity is the point here. I think it has became available on a range of platforms because its source was available and there was sharing among universities. Since the factual acuracy of the sentence can become dubious just by using a point of view, then it's obvious that the sentence itself has a point of view and needs a citation.
• K&R C was often considered the most basic part of the language that a C compiler must support - how often ? who often considered that ? this sentence doesn't mean anything because of the weasel words. It could only make sense with a citation
• After a long and arduous process - It was not arduous. It was a really simple and happy process.
• C compilers exist for nearly all processors and operating systems - WP:WEASEL, WP:PEACOCK
• and most C compilers output is well optimized - blablabla

Concerning scattering facts throughout the article: nothing cited is borderline, the facts were not inserted in random places, I don't have, by any means, to seek any information that I or anybody else would ever want and finally: with or without facts cluttering the text, the text either doesn't cite sources or doesn't agree to a neutral point of view. The absence of indication can't hide the low quality content of the article. Believe-me: it's better when an article says "I suck" than when it just sucks (why ?).

• system developers and implementors know well that C is the common language most likely available for new hardware or a new processor architecture^{[citation needed]} WP:WEASEL, WP:AXS

• --hdante 01:03, 31 July 2006 (UTC)

• I agree that simplicity wasn't the main reason C was available on a number of platforms, although if it were hard to write a C compiler things might have been different. Originally it was because, if you could create a basic C compiler, you could have a complete OS for your new hardware, since Unix was pretty much totally written in C. Once gcc came along, it was extremely easy to create a C compiler for a new hardware platform, since gcc supported cross-compilations fairly easily.

• In the early days, if you were a C compiler vendor but if you didn't support K&R C, then you need not bother trying to sell your product. That was the "bare necessities" of C compilers. K&R was the only official document for the C language, so each compiler had to support K&R at a minimum. Can anyone come up with an example of a C compiler that had any kind of market penetration, but didn't support K&R? Even after ANSI C came out, the compilers still had to support K&R because of the large code base already written in K&R. In fact, I have a routine available on my web site that is still written in K&R ... I've never bothered to convert it to ANSI because it works fine the way it is.

Supporting K&R C wasn't a big deal, C vendors were busy adding more and more features because of competition and a desire to improve on C (hint: performance). ANSI C incorporated a lot of those improvements (like assert). —Pelladon 07:46, 4 August 2006 (UTC)

Then your memories are distinctly different than mine. I recall once when we refused to buy a new model from one of our mainframe vendors because it didn't fully support K&R. A NULL pointer wasn't zero, but had some addressing info in the higher bits. As a result, if you used something like if (ptr), a NULL pointer would not return a false. We told them that was unacceptable. There was too much existing code that used that construct.

Any compiler that didn't support K&R was immediately disqualified for any purchasing decision. As for enhancements, when I wrote the coding standards for a project, I explicitly said not to use extensions, since that would lock them into that vendor. Performance was more a function of the hardware, not the compiler. Remember, back then there wasn't any common platform that everyone used. We didn't even have a single form of Unix, so we had to code for BSD/System V differences. If you depended on a particular compiler vendor, then you could only purchase the hardware that they supported, which removed one of the big arguments in favor of Unix. wrp103 (Bill Pringle) 13:06, 4 August 2006 (UTC)

I didn't realize that there were vendors that didn't support K&R, I'm surprised they did that (especially in the early days). —Pelladon 05:52, 9 August 2006 (UTC)

• It took 6 years to develop the C standard, and a fair amount of negotiation had to take place to make sure everybody was happy with the result. So long doesn't seem to be much of a stretch, although I'm not convinced about arduous. Is there any citation about the process being simple and happy?

• But C compilers do exist for most platforms and operating systems. If you were to make a list of the platforms/OS combinations that didn't support C, it would be very easy to come up with a much longer list of those that do.

• C has long been recognized as being highly optimized, especially since gcc came along with excellent optimizations options. Since the C language is small and simple, compiler output, (even without any optimization) tended to be smaller and faster than most high level languages in the early days (you should have seen the original code generated by PL/I!). In fact, it is only recently that a case has been made that maybe C isn't as optimized as some think, as can be found in this SlashDot article, and that is mostly because of hardware features that are hard to take advantage of in C.

Where I teach (PSU Great Valley), we assume that all students taking IT classes know C. They may not be an expert, but the basic remedial programming classes are taught in C, and the assumption is that anyone who has been programming for any amount of time has run across C. (And if they haven't, they can pick it up fairly quickly.) Even though C isn't really meant for beginners, it is still taught for intro classes in many schools. I have a "Programming for Poets" type class that I put together that uses a combination of C and VB.

With the possible exception of some highly specialized embedded systems, I think you would have a hard time coming up with a decent sized list of platforms/systems that don't support C. If somebody can produce such a list, I would be interested in seeing it. wrp103 (Bill Pringle) 04:14, 31 July 2006 (UTC)

Without getting into details, I was involved in a similar fight for citations on Programming language. Basically, I feel that Wikipedia policy is that many things that you "know" are true (perhaps due to professional experience) still need to be cited. Remember the policy of "Verifiability, not truth". This article recently was removed as a Featured Article primarily for lack of citations, so it certainly needs more. I also do not agree that it is lazy to add {{fact}} tags without finding the citations yourself. In the past I have had success getting people to find citations once I explicitly listed where they were needed. --Ideogram 05:59, 31 July 2006 (UTC)

Concerning wrp103 response: it's obvious that you didn't understand what I've meant. I don't really agree or disagree with any "fact" I have written here in the talk page. Actually I agree with some things that I've tagged as needing citation, which means absolutely nothing to Wikipedia. Please, read again my arguments, having in mind that if such weak "facts" that I've written here were able to start a discussion, then the main article could not possibly be in a neutral point of view. --hdante 12:34, 31 July 2006 (UTC)

BTW (offtopic) There's no sense in talking that the C compiler is more or less optimizing. AFAICT, two-pass compilers just can't compete in optimization with multiple-pass (front end/back end) compilers. And multiple pass compilers use an intermediate representation to handle their data, so that it's independent of programming language. Early compilers were simple, not optimizing. Simplicity and optimization are not friends. I don't know what have you done in compiler optimization, but your talk seems to be outdated. --hdante 12:46, 31 July 2006 (UTC)

My experience is actually that C is extremely difficult to optimize. It's only been optimized as much as it has due to a great deal of focused research on procedural programs in particular, which is largely because of C's predominance. Early compilers certainly struggled to optimize even simple C programs due to complex issues of potential aliasing due to pointers, variables with long live ranges, and so on. I think if we're going to construct a discussion of why C programs are often more efficient than similar programs written in other languages, it should focus primarily on the level of detailed control given to the programmer, the efficiency of its primitive operations, the lack of overhead from a runtime infrastructure, and so on. Deco 20:54, 31 July 2006 (UTC)

Which is similar to what I was trying to say. Because the language was simple, the output tended to be more compact than more ambitious languages. For example, early PL/I compilers would translate something like if (a<b) x=y into 25-30 lines of machine instructions. I couldn't believe it the first time I looked at it, but because of all the various options within PL/I, and the fact that it wasn't too good at type checking, much of the code was spent determining the type of each variable, what option(s) were being used, as well as determining the correct operators. Compared to many other languages, C doesn't do that much "behind the scenes". The translation from source code to machine language is pretty straight forward.

Also remember that the things many people think about when discussing compiler optimizations these days weren't even dreamt about, let alone attempted, during the early days. Sometimes we were happy if the program worked correctly. I remember having a problem with a PL/I program shortly after the language was released. The solution was to rearrange the order of some functions. I was told: "Sometimes that fixes things!" ;^) wrp103 (Bill Pringle) 21:25, 31 July 2006 (UTC)

Hello ? If nobody has anything else to say, I'm reverting the article. --hdante 14:07, 1 August 2006 (UTC)

You might want to wait for an answer when you ask a question. wrp103 (Bill Pringle) 14:27, 1 August 2006 (UTC)

All this 'citations needed' stuff is ridiculous. The things demanding citations are not contentious at all. I have to think that the people demandinsg them are citation trolls. The whole thing makes wikipedia look like a big fat joke. - RichardAdams

Okay, I have addressed the "need citations" issue by rewording the statements in question into less controversial forms. In some cases, parts of the text was redundant with other statements elsewhere in the article, so I eliminated those redundancies. I don't think I lost any significant information, and I think the rewording is generally clearer. Since there are now plenty of references and no remaining flagged disputes about factual matters, I removed the "references" tag. If there are still disputes, feel free to add back some flags, but perhaps first you should discuss the specific issues. DAGwyn 23:23, 29 August 2006 (UTC)

[edit] Reasons for not promoting

Hi all,

I was very close to promoting this article to a good article. But I felt it was still in a state of transition and needed some further refining. My two main suggestions are:

• Fix the citation tags.
• Move the criticism section (4 screens worth) to a sub-page and summarize it in the main article.

Cedars 00:44, 7 August 2006 (UTC)

Since when has there been this disturbing trend to move only criticism off to a subpage? If anything, a discussion of pros and cons must take place -- not outright criticism. Dysprosia 00:49, 7 August 2006 (UTC)

Maybe it is my fault. I have done this for the Java criticisms section, because it has become very long and confusing for the reader and some of the critics could really be objected. I think we should have a normalized way to deal with pro and cons for computer languages. Some of them have no criticism sections at all : ADA, Basic, Fortran, C#, Python, Perl, Ruby (almost no critics). Some of them have several pages of them (this is the case for Java, and for C). The length of the criticism section does not say anything about what are the real cons for a language, so I think that to have a standard way to present pros and cons would be fair. Hervegirod 23:36, 7 August 2006 (UTC)

I agree with the idea that the criticisms section is unduly long compared to the rest of the article, and could be moved to a new (sub)article "Criticisms of C", with a summary mention of some of the main complaints. I think the citation policy is being carried to an unreasonable extreme here; except for the bit about optimization (which I think has rightly been removed), the flagged statements about C's ubiquity and significance are generally well established in the industry and known as such by personal experience of several independent contributing editors, who have as much credibility as any reference that could be cited, such as a survey in some trade magazine. (Such studies usually exhibit poor statistical methodology anyway.) If an article were to say that the Sun is very bright, would a citation be required? DAGwyn 10:24, 27 August 2006 (UTC)

I also think the "hello, world" example would be better as a separate, linked subarticle. DAGwyn 10:29, 27 August 2006 (UTC)

Speaking of the hello world example, the function prototype should be int main(int argc, char **argv). Is there a specific reason not to have this?Kreca 10:47, 27 August 2006 (UTC)

Both int main(void) and int main(int argc, char **argv) are equally valid definitions. If you are not going to use argc and argv, then why bother defining them?Mrjeff 09:24, 28 August 2006 (UTC)

That's right (there are these two distinct valid interfaces for main, according to the C standard), and even worse than that C99 allows the return to be omitted (for main only), automatically assuming return 0. I don't think it is useful to explore that in an introductory article. DAGwyn 20:49, 29 August 2006 (UTC)

Turns out that there is already a "hello world program" article, more general than just about the C example, so separating out the "hello, world" section would be problematic. DAGwyn 20:55, 30 August 2006 (UTC)

I moved the criticisms section to a separate article. It would benefit from some slight clean-up, in particular I didn't (yet) summarize the criticisms in the main page, just inserted a link to the new article. After that is done, the C article should be re-submitted as a "Good article". DAGwyn 21:58, 30 August 2006 (UTC)

I cleaned up the remaining "Criticism" section a bit more. It may be good enough to try resubmitting as a "Good article" now. I haven't yet done that, in order to provide some time for evaluation of the changes and discussion, if necessary. DAGwyn 04:07, 31 August 2006 (UTC)

Doing so is not in adherance with NPOV, unless you title the page differently, and include countering viewpoints. Any page including criticism must be balanced or Wikipedia takes a non-neutral view on a topic, which is not permitted. Dysprosia 04:26, 31 August 2006 (UTC)

That is a misunderstanding of WP:NPOV. C programming language, criticism does not criticise C, it describes existing criticism of C (and, from a glance, in a reasonably neutral manner, neither endorsing nor rejecting this criticism). Moving this to a seperate article is fine. I don't know if the name is perfect, but the concept is ok. It could use some sources, though. --Stephan Schulz 06:46, 31 August 2006 (UTC)

No. Presenting only criticism without response or other positive views is unbalanced and hence presents a one-sided view on a topic. That is not NPOV. Dysprosia 12:47, 31 August 2006 (UTC)

Note first of all that I did not create the C criticism text — it was already embedded within the main C programming language article, and I was merely responding to the requirement expressed at the start of this discussion topic that the criticism be moved to a separate page. Next, note that Stephan is correct in his observation that the criticism text is merely reporting on a factual matter, and is fairly well balanced, not just negative POV. Indeed, as one of the oldest proponents of C and a longstanding member of its standards committee, if I thought it had been too negative I would have added some counterbalancing comments to it. You can do so yourself if you think it necessary. What I am looking for feedback on is the act of moving that text to a separate article, not the (pre-existing) content of that text, which by the way now has its its own discussion page. DAGwyn 04:30, 1 September 2006 (UTC)

I'm not opposed to having the text. I'm opposed to it being the only thing in the criticism article (because, as I've outlined, doing so without balance isn't NPOV). There is no very strong reason that I can think of for having content based on analysis in another article. And as you suggest, I intend to look over the article for problems when I have some time. Dysprosia 02:06, 3 September 2006 (UTC)

Note the very first entry in this section, which seems like a pretty clear requirement to move the criticism section to a separate page. I think links are a useful tool for reducing clutter in main-line text. Also, the criticism section does have a fair amount of balance — and it really is undeniable that several of C's characteristics can be problematic for some people in some contexts, so the overall gist of such a section has to seem somewhat "negative". I did find a less-than-balanced piece of it a day or two ago and made it more neutral. Further contributions would be welcome, but let's try not to turn the criticisms article into a debate. — DAGwyn 05:55, 4 September 2006 (UTC)

I wasn't planning to. I haven't had a chance to have a close read of the article, but if the article is as balanced as you say, then there's no need to call the article a criticism of C, but more an analysis of the language with issues that people have found. Dysprosia 07:49, 4 September 2006 (UTC)

Criticism is not necessarily negative! --Stephan Schulz 08:28, 4 September 2006 (UTC)

This is true, but it's most common connotation is negative, and may be construed as such. That is undesirable. Dysprosia 12:05, 4 September 2006 (UTC)

[edit] Forth is lower than c

Forth is used quite a lot in bios or embedded devices where size is a issue. The new intel and amd64 are apparently written in plain c. Allix Fri Sep 1 13:59:01 BST 2006

So how is this supposed to bear on the C article? Also, your second sentence makes no sense. — DAGwyn 08:01, 2 September 2006 (UTC)

[edit] Requested move

C programming language → C (programming language) – Conformance with WP naming conventions LotLE×talk Note: Please notice the below info box. This is not a poll about C specifically, but about PLs in geeneral, many (but not all) of which use the pattern "FOO programming language" rather than the general WP disambiguation pattern "FOO (programming language)".

[edit] Pages like C programming language, criticism

To meet the new standard, the pages should be moved to something like Criticism of C (programming language), right? examples are Georgia (U.S. State) and Politics of Georgia (U.S. state). atanamir 02:42, 5 September 2006 (UTC)

Depends on the page in question, most likely; some would work like above, some (like C syntax) wouldn't require any changes, and some might want to use a different method to disambiguate. --Piet Delport 05:55, 5 September 2006 (UTC)

Agreed with Piet; only the ones that would incite ambiguity -- simply "Criticism of C" would have ambiguity, but "C syntax" or "Syntax of C" are both rather unambiguous and would not need change. atanamir 06:01, 5 September 2006 (UTC)

Surely, criticism of C is pretty unique and should be the article? Are there any other C's that would be criticized? Aaron McDaid (talk - contribs) 21:41, 5 September 2006 (UTC)

I agree that the most likely "C" to be criticised is the programming language, but some may be looking for a criticism of the letter or magazine. Unlikely, but possible. This decision would be left up to the community, though. atanamir 01:57, 6 September 2006 (UTC)

As of now, there is only one C that is criticized on Wikipedia, and I am not aware of anyone wanting to write an article criticizing any other Cs. Therefore, criticism of C is unique. The Wikipedia standard is to only disambiguate when necessary. That article should be moved to criticism of C at some point, but we should let this debate finish first. Aaron McDaid (talk - contribs) 09:16, 6 September 2006 (UTC)

For the record, "Criticism of C" didn't even exist until I created the redirect yesterday. Was kind of surprised because it was at that wierd, longish name and is a pretty good article :). RN 10:19, 6 September 2006 (UTC)

The C criticism article was split off from the main C article, where it had previously been embedded, in response to a requirement in order for the main C article to be designated a "Good Article". I picked the name with the idea that it was a sub-article of the main one. Once the discussion has settled, I don't object to some reasonable renaming, so long as the links between the two articles are fixed up so they still point to each other. — DAGwyn 21:51, 6 September 2006 (UTC)

Aaargh! Whoever just renamed the main C article ignored this linking issue. I have edited the C criticism article so its link to the C article does not have to redirect. — DAGwyn 20:20, 7 September 2006 (UTC)

The term "criticism" should not be used (I've stated reasons for this on Talk:C (programming language); the more accurate term of "analysis" or something similar should be used. Dysprosia 03:54, 7 September 2006 (UTC)

You also received feedback to the effect that criticism doesn't have to be negative, that the article is fairly balanced, and that a list of limitations has to seem somewhat negative no matter how well-intentioned it may be. The C criticisms article is not at all a complete analysis of the language, just a description of the many characteristics of C that have drawn reasonable criticism. Since C is so popular and wide-spread, it is a target for a lot of sniping and second-guessing, and it is undeniable that that has happened, which is part of what the C criticism article specifically addresses. One of the useful functions of the C criticism page is to bring some balance to that criticism. — DAGwyn 20:20, 7 September 2006 (UTC)

I also responded to that comment by saying (and I'll repeat the comment here for the benefit of readers of this page) that the term "criticism" still has primarily a negative connotation and that because of this it is an undesirable term. The article in question has the potential to contain discussion on design points on the language and opinions on those who comment on these design points. That is an analysis of the design of the language, and has the potential to encompass views from all points on the spectrum on the matter. Dysprosia 07:43, 8 September 2006 (UTC)

I just want to chip in that i agree with DAGwyn that "criticism" does not carry negative any primarily negative connotations in this context. As the criticism article says:

"In literary and academic contexts, the term most frequently refers to literary criticism, art criticism, or other such fields, and to scholars' attempts to understand the aesthetic object in depth."

There are certain fields ("In politics, for instance [...]") where "criticism" connotes mainly negative criticism, but it should be reasonably clear that encyclopedias won't limit themselves to that. --Piet Delport 23:32, 10 September 2006 (UTC)

Technically, it shouldn't carry any as you suggest but most seem to think it is a dumping ground for it. I would recommend "Analysis" as that's what I'm doing for criticism page I watch. RN 23:43, 10 September 2006 (UTC)

"Analysis" usually implies something more formal, complete and reductionistic, though. Is that what the article is aiming for? --Piet Delport 00:00, 11 September 2006 (UTC)

It doesn't need to imply that. The article in question however should aim to examine as many viewpoints on as many language points as possible. Dysprosia 02:33, 11 September 2006 (UTC)

Unfortunately, the C (programming language) article itself does force the negative connotation on the reader by saying "Despite its popularity, C has been widely criticized. Such criticisms fall into two broad classes: desirable operations that are too hard to achieve using unadorned C, and undesirable operations that are too easy to accidentally achieve while using C. Putting this another way, the safe, effective use of C requires more programmer skill, experience, effort, and attention to detail than is required for some other programming languages." That whole paragraph implies that the article Criticism of the C programming language is negative (why else say "Despite its popularity" and then cite two negative classes?) Mickraus 17:14, 24 January 2007 (UTC)

[edit] Burroughs MCP use of ALGOL?

I thought MCP was written primarily in ESPOL, which was a proprietary SIL that somewhat resembled ALGOL. — DAGwyn 09:34, 2 September 2006 (UTC)

I checked the reference manuals, and ESPOL is closely enough related to ALGOL that there is no need to adjust the current statement in the article. — DAGwyn 21:43, 7 September 2006 (UTC)

[edit] Failed GA nomination

I failed this article due to the fact that there are only nine references for a 49 kilobyte article. Besides that, it's great! Some P. Erson 00:06, 9 September 2006 (UTC)

[edit] Hello, world example

I tried using two different compilers (VS and gcc) and neither compiled main() { printf("Hello world"); }. They both assumed that main was an int and both assumed a default return value of 0, however they didn't "auto-include" stdio.h, and therefore they both gave a printf() not defined error. Are you sure that it is correct? Did anyone try to compile it? --Swalot 00:25, 17 September 2006 (UTC)

If you would have read the article closely, you would have seen these sentences: The above program will compile correctly on most modern compilers that are not in compliance mode. However, it produces several warning messages when compiled with a compiler that conforms to the ANSI C standard, and won't compile at all if the compiler strictly conforms to the C99 standard.

The example following it is presumably what you want. Dysprosia 01:48, 17 September 2006 (UTC)

I did read it closely, and that's why I used the most recent versions of VS and GCC, without the ANSI flag. And it wasn't a warning, it was an error. --Swalot 02:26, 17 September 2006 (UTC)

gcc accepts it fine:

$ cat > test.c
main() { printf("blah\n"); }
$ gcc test.c
test.c: In function 'main':
test.c:1: warning: incompatible implicit declaration of built-in function 'printf'
$ ./a.out
blah

and that was from gcc 4.0.3. Not including header files doesn't mean that your program can't be linked. Dysprosia 02:38, 17 September 2006 (UTC)

ok, sorry then :( --Swalot 03:16, 17 September 2006 (UTC)

Don't be sorry, at least we've resolved the matter :) Dysprosia 05:19, 17 September 2006 (UTC)

Note that the first form of the program was meant to illustrate what C was typically like in pre-Standard days. Perhaps that should be made clearer. — DAGwyn 06:06, 18 September 2006 (UTC)

[edit] C

Sir Since default data type of pointer variable is int, then how can it store value more than 32667. your faithfully Neeraj Pandey

This page is for discussions about the Wikipedia article "C (programming language)". Questions about C programming should be posted to the net newsgroup comp.lang.c instead. However, the simple answer is that your statement is wrong: pointer variables have their own specific types, which are never type "int", and while many C implementations do allow pointer values to be converted to and from some integer type without loss of information, that type isn't necessarily plain "int". Also, on many platforms type int can represent values much larger than 32767. — DAGwyn 19:22, 29 September 2006 (UTC)

[edit] C++ superset of C

Unless my memory is going, the original implementation of C++ was a preprocessor that translated the language into C, and then it was compiled with a regular C compiler. That is why I said it was originally a superset of C. Of course, saying it is nearly a superset of C is correct regardless of the state of my memory. ;^) wrp103 (Bill Pringle) 21:31, 27 October 2006 (UTC)

It is true that early implementations of C++ (and its forerunner "C with classes") used a preprocessor. However, they completely parsed the source language, and interpreted some things differently from how C compilers interpret them, so that the generated C source text was often not just a simple "copy through" of the C++ program source text. For example, "extern int foo();" declared the function as definitely not accepting any arguments (what is now known as "extern int foo(void);" in Standard C), whereas in C the same syntax has always declared the function as having unknown argument types. Also, character constants 'x' have type char in C++ but type int in C. There are other differences, too; see Tribble's page for more detail. There is a "common subset" of C and C++ that some programmers try to remain within, so that their code works under compilers for either language. But it's smaller than "all of C". — DAGwyn 06:13, 31 October 2006 (UTC)

Some versions of C++ still output C, and then expect you to compile that using a C compiler. However, some Haskell compilers do the same, and I don't think anyone would claim that Haskell is a superset of C :) Mrjeff 10:23, 31 October 2006 (UTC)

C++ came about before ANSII C, so the compiler didn't complain about how many arguments were used. What you are describing might be how some C++ compilers work now, but it wasn't the way the first OO versions of C worked. wrp103 (Bill Pringle) 14:20, 31 October 2006 (UTC)

Well the first C++ compiler was Cfront. [1] describes how it worked. The "C with classes" compiler could be described as you say, but the first compiler for C++ did it's own checking. Mrjeff 16:54, 31 October 2006 (UTC)

Yes, Pringle is simply wrong. The relevant "compiler" is the C++-to-C translator, not the back-end C compiler; the Haskell example should illustrate the point that one can't infer any similarities between the two languages just from the preprocessing construction. Even "C with classes" did function parameter type checking (at least within a translation unit). The types were also enforced for external names via the "name mangling" that embedded that type information into the interface, so that a mismatch would be caught by the linker.

[edit] A small set (around 30) of reserved keywords

Technically correct, and true in it's original context (as a system language), but a bit misleading. Look for example at the "Hello World" example. Is that written in C? With C? or what? Which part of C is sprintf? And if it's not part of C, why is it the classic example? Which part of the 'characteristics' section tells you that standard C includes standard libraries? I don't have a solution, but there is a disconect between that typical definition of C, and the language as actually used: that definition is of only technical importance, and not related to the language being demonstrated, which has hundreds of key words, which you can redefine, but don't. 218.214.148.10 01:37, 6 November 2006 (UTC)

C is fairly cleanly partitioned into: preprocessor, language, and library. This should probably be made clearer at the start of the "characteristics" list. DAGwyn 20:56, 7 November 2006 (UTC)

218.214.148.10, the use of library functions was well-known by the 1970's, where a library call was understood not to be part of the language, but a call to a facility provided by the operating environment, which tremendously simplifies the programming, and allowed a clean separation between implementation and language design. Some examples of this point of view can be found in languages like Jovial, which had no I/O. Thus Hello, world was an advance, because you could write a program without also writing the I/O library. See Free On-line Dictionary of Computing for more of this type of CS history. --Ancheta Wis 04:16, 14 December 2006 (UTC)

[edit] relatively simple compiler

"Among its design goals were that it could be compiled in a straightforward manner using a relatively simple compiler,"

Is that supported by the historical documentation? (please excuse my ignorance). If so, what was it in comparison to? There seems to be pretty general agreement that regardless of the original design goals, C actually requires a comparatively complex compiler. (Or you can use a restricted C compiler. Or you can use a C compiler with wrong bits.)

Which falsifies the next bit "As a result, C code is suitable". Regardless of the historical design goals, C requires a complex compiler. Compiler simplicity is not why it is suitable for system design tasks. If simplicity of compiler was the criteria, FORTRAN or Pascal would be more suitable, which in general they are not. 218.214.148.10 02:20, 7 December 2006 (UTC)

Well, C evolved from relatively simple beginnings. The main contributor to the rapid spread of C on other than the original PDP-11 platform was undoubtedly the development of the "Portable C Compiler", which drastically reduced the amount of work needed to create a C compiler for a different target architecture. There were several stages in the evolution of the PCC, too.Of course these days everybody uses GCC for a similar purpose. — DAGwyn 23:54, 7 December 2006 (UTC)

A possible relevant comparison would be PL/1 (the original application for C was to be the implementaion language for Unix, whose predecessor Multics was written in PL/1), which by all accounts was a horribly complex language to write a compiler for. C, and especially early K&R C, is in fact rather simple to compile. A graduate student equipped with a LALR parser generator could probably implement a working compiler for K&R C from scratch in a few months. It wouldn't produce terribly good code by today's standards, mind you. (Newer versions of the language have added some complications, of course - e.g. parsing complex declarators in the presence of typedef names is not for weenies). Much of the relevant competition in the early 1970's need quite ad-hoc parsers and do not have the clean separation between core language and library that make C compilers so simple. Your suggestion that FORTRAN compilers would be simpler to write than C ones strikes me as so wrong I don't even know where to start refuting it. Henning Makholm 05:29, 10 December 2006 (UTC)

In my experience (which goes way back and includes FORTRAN and C compiler construction), constructing a compiler for FORTRAN versus C around 1975 would have required roughly the same amount of work, assuming a reasonably clean ISA. Fortran's run-time support library would have been somewhat larger, since it couldn't use early C's trick of mapping shorter data types into longer ones, and also had to support built-in I/O facilities. (For a fairer comparison, one should add at least the stdio package to the implementation.) There were contemporaneous languages that had features that required more complicated compilation, e.g. "thunks" for some procedure parameters in Algol. Even so, building a whole compiler from the ground up would still require a simialr amount of work. The actual attribute of C that I think should be mentioned instead is, C programs had a "transparency", such that one could pretty much predict the machine code that would result from a given source, especially on the PDP-11. Without built-in exponential (FORTRAN **) and array operators, there was little or no hidden execution cost in C source code; if an algorithm took yay many patent source-code operations, it took a comparable number (expanded by some small factor, on the order of 2) of machine operations. — DAGwyn 21:01, 11 December 2006 (UTC)

I second your opinion on the "transparency" of C code, that's one of the reasons why C could be compared to a portable (machine independent) assembly language. /HenkeB 16:56, 1 March 2007 (UTC)

218.214.148.10, For some historical documentation, there are implementations of C which were based on recursive-descent parsers, such as Small-C (Ron Cain 1980) which were useful for the early microprocessors (no floating-point values), and which are still in use for embedded systems. See Dr. Dobb's Journal for Ron Cain's work. --Ancheta Wis 03:59, 14 December 2006 (UTC)

I believe that first compilers were simple. There are current compilers that support this fact. In particular, the Obfuscated Tiny C Compiler that was made for the 2002 IOCCC has a little more than 2048 bytes source code. Also, its evolution, tcc is a pretty much complete C compiler, assembler and linker has a 100 KB binary executable. --hdante 12:47, 6 January 2007 (UTC)

Tiny C was designed to be exactly that subset of C for which a simple compiler was possible. Thus, the mere fact of Tiny C might indicate that C itself is too much for a simple compiler. — DAGwyn 00:39, 14 January 2007 (UTC)

Or one could say that Tiny C was designed to be compiled in a straightforward manner using a relatively simple compiler, relative to C. :) – Smyth\^talk 16:28, 14 January 2007 (UTC)

[edit] Negativity of this article

Am I the only one taken by the overwhelming negativity of this article? All it seems to cover is its limitations rather than its strengths, and what features it lacks and criticism but barely highlights its upsides and that many of the so called criticisms are intentional design decisions. Every other sentence seems to be "C doesn't have such-and-such". Contrast this to Pascal (programming language) or Python (programming language), where there is barely any criticism. I feel having the sheer amount of negativity leaves the impression that C is a 'bad' language and as such this isn't a neutral article. -Halo 12:05, 3 January 2007 (UTC)

I wrote the negative sections of this article and C is my favourite language. This may have to do with some of the more positive sections being moved out to other articles. In any case I don't think there's a POV problem - although we could certainly do with more information on its successes. Deco 12:13, 3 January 2007 (UTC)

C attracts criticism partly because it is so successful. Its success is also mentioned in the article. A while back I moved the Criticisms section to a separate article to restore some balance. C is like a sharp knife: preferred by expert whittlers, but dangerous in unskilled hands. — DAGwyn 04:46, 4 January 2007 (UTC)

Hi, I think you are right. It would be more encyclopedic if we concentrated on what C can do and move most criticism to its own section or Criticism of the C programming language. This may improve the article quality and simplify some sections. --hdante 21:44, 4 January 2007 (UTC)

Generally I agree; for example the list of features that C lacks could be merged into the Criticism of the C programming language article, leaving in the main C article the list of features that C has. — DAGwyn 06:56, 6 January 2007 (UTC)

I would also like to remark that a lot of the criticism, particularly listing features that C lacks, seems POV and slightly misses the point of the language. Criticising C for not having built in garbage collection is like criticising Python/PHP for not having pointers - it's true, it's accurate, but kinda misses the point -Halo 09:58, 6 January 2007 (UTC)

This kind of criticism may be simplified if we say that C is often used as an application language, instead of a system language and then give examples of such criticisms (like lack of garbage collector) to show that people miss the point. However, I don't have a reference to back it up. --hdante 11:51, 6 January 2007 (UTC)

[edit] Binary operator associativity

I could swear saw some code demonstrating that certain lines' output (something like "a++ + ++a") was not defined/compiler specific because the associativity of + and * is not specified. Yet this article lists them all as L->R associativity... Is this correct? The samples I saw may have been C++ but I don't think the languages differ in this area. AllUltima 00:46, 8 March 2007 (UTC)

Operator precedence and sequence points are separate concepts. a++ + ++a is undefined because a is modified twice without an intervening sequence point. The associativity of the operators is unimportant. Pfaffben 05:56, 8 March 2007 (UTC)blp

Pfaffben is right about them being different concepts; pre- and post-increment dont really fit into the precedence table well because pre- and post-increment are different beasts depending on where the same syntax sugar is placed. The FAQ's for C and C++ both address this exact scenario of more than one increment operator without sequence points. Enjoy the read. John Vandenberg 07:00, 8 March 2007 (UTC)