Talk:C (programming language)/Archive 9

This is an archive of past discussions about C (programming language). Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 5

←

Archive 7

→

Any suggestion to improve?

I've added my website [1][c-programming-guide.com] to the tutorial session, but it has been removed. Any suggestions for me to improve my website? —Preceding unsigned comment added by 155.69.5.236 (talk) 14:08, 31 August 2007 (UTC)

In general, it is not proper for anyone to add their own web site to any article. -- wrp103 (Bill Pringle) ^(Talk) 05:56, 1 September 2007 (UTC)

originally used vs predominantly used

There has been a back and forth discussion about whether the intro should state that C was "originally used" or "predominantly used" for systems software. There is no doubt that C was originally used for systems software, but the question is if it is now "predominantly" used for systems or application software. The two citations following that sentence say that it was originally used for systems software, but I couldn't find any claim that it is now predominantly used for either.

It might be that C is now mostly used for applications, but until we can find a citation that makes that claim, it seems to me the sentence should use "originally." If we find a citation that says C is mostly used for application software, then I suggest that we change the sentence to:

Although originally<ref>original footnotes</ref> used for [[system software]], it is now predominantly<ref>new citation</ref> used for [[applications]].

Comments? -- wrp103 (Bill Pringle) ^(Talk) 15:57, 2 October 2007 (UTC)

You have misstated the issue. The intent of the sentence is to indicate what C is most useful for, and that is unquestionably systems programming, which is indeed what it was originally designed for. Of course it has been used for applications also, especially on early Unix systems which offered few viable alternatives (typically only Fortran and Bourne shell). These days, however, most apps are coded in higher-level languages such as Perl, PHP, TCL, and C++. C remains the predominant systems implementation language; more often than not those higher-level languages and their run-time libraries are themselves coded in C. C is heavily used for embedded systems development, especially for the scheduling/IPC/device/interrupt support.

The introductory sentence needs to convey this fundamental aspect of C usage. Your change to "originally" gives an impression that is contrary to the reality; it makes the reader think that although C started out being used for systems programming, its use has changed over time to mainly applications. Rather the opposite has occurred; while a significant fraction of C's use shortly after its invention was for apps, that fraction has become smaller in recent times, due in large part to the more convenient and effective facilities offered by higher-level languages.

If the references don't properly reflect this, then better references are needed, not a change to the text to give the reader a wrong impression. — DAGwyn 23:01, 2 October 2007 (UTC)

If somebody can find a reliable source that states whatever C is mostly used for, we can use it. I don't read the sentence the way you are interpreting it. I will tweak it to reduce that conception. However, I stand by the fact that the citation only states that C was originally used for system programming, and until we can find another citation, we can't state what it is usually used for today. -- wrp103 (Bill Pringle) ^(Talk) 00:35, 4 October 2007 (UTC)

I agree with wrp103 (Bill Pringle). Derek farn 07:21, 4 October 2007 (UTC)

I have further tweaked the sentence; hopefully it will now satisfy all interested parties. C has always been used for both systems and applications. It is certainly not the best choice for most modern applications, and has largely been supplanted by Perl, Python, C++, and other languages in that capacity. However, it remains very important for systems implementation, not having been supplanted in general in that area (despite having some deficiencies). My concern with the previous revisions is that they could easily have been read as saying "C was once used mainly for systems programming, but is now more often used for applications", which gives an entirely wrong impression. — DAGwyn 20:16, 4 October 2007 (UTC)

Array-pointer interchangeability error?

In the array-pointer interchangeability section, the four "equivalent" examples at the bottom are not necessarily equivalent, and do not attempt to demonstrate the same point as the rest of the section.

Contrary to what the example suggests, *(x + i) will result in an address (x + i*sizeof(*x)), whereas *(i + x) will result in an address (i + x*sizeof(*i)). Clearly, if sizeof(*x) and sizeof(*i) are not both equal to one, these will not be equivalent.

Also, I'm not even sure if this is really valid C (I can't get it to compile with either MSVC or gcc without casting), since "x designates an array". Either way, this example does not belong in this section. —Preceding unsigned comment added by 69.245.208.25 (talk) 04:25, 5 October 2007 (UTC)

The article text is correct. i+x does *not* result in an address i+x*sizeof(*i); subclause 6.5.6 of the current C standard explains what happens. The pointer operand is treated the same way in this regard, no matter which order the operands have. The example also strictly conforms to the C standard. I don't know why you didn't get it to work, but try the following strictly conforming program:

#include <stdio.h>
static int i = 3;
static double x[10];	/* x designates an array */
static void dump() {
	int k;
	for (k = 0; k < 10; ++k)
		printf("%g%c", x[k], k<9? ' ': '\n');
}
int main() {
						dump();
	x[i] = 1;	dump(); x[i] = 0;	dump();
	*(x + i) = 1;	dump(); *(x + i) = 0;	dump();
	*(i + x) = 1;	dump(); *(i + x) = 0;	dump();
	i[x] = 1; /* strange, but correct: i[x] is equivalent to *(i + x) */
			dump();
	return 0;
}

The example certainly does belong in the section, since it illustrates the exact meaning of i[x] in C, which is quite unlike most other languages. —Preceding unsigned comment added by DAGwyn (talk • contribs) 15:24, 5 October 2007 (UTC)

C99 Expanded to its own page

I am interested in expanding the C99 section to its own page and including code snippets. The one on this page can stay as is with a pointer to the new page for more details. Does that sound good to you? Daniel.Cardenas 22:00, 14 October 2007 (UTC)

What would be the purpose? Especially of "code snippets"? Of course, if there were to be a separate C99 page we would plant a link to it in the C page. — DAGwyn 05:04, 15 October 2007 (UTC)

Better more detailed explanation of C99 changes. Daniel.Cardenas 13:59, 15 October 2007 (UTC)

So I guess you'd want a link after the list in C99/New features? Note that apart from new features, there were very few substantive changes from the previous spec (C90). The main one worth noting is the removal of implicit "int" in declarations. ("long x;" is still OK, but "register x;" isn't.) — DAGwyn 16:07, 15 October 2007 (UTC)

Done. Chris Cunningham (not at work) - talk 10:22, 23 June 2008 (UTC)

Developer - Dennis Ritchie only ?

Well i believe that this was not only Dennis Ritchie. But also Ken Thompson who initiated and developed for example ++ -- unary operators with it's position relative application. In papers i read from Dennis there was Ken "everything" Ken "everywhere", well there are only 2 links to him. It feels to me like he is somehow forgotten, isn't he? Cc..aa..ll (talk) 10:14, 8 December 2007 (UTC)

The Bell Laboratories team that developed Unix discussed a lot of ideas among themselves, and a suggestion by one person might be developed by another. The initial development of C is generally attributed to Dennis Ritchie, with some later additions due to Steve Johnson. Ken Thompson changed to C instead of assembly language for the Unix kernel only after structures were added to the language. Thompson is given primary credit for developing Unix; he also was co-developer of the chess machine Belle and produced the kernel for Plan 9. — DAGwyn (talk) 19:06, 10 December 2007 (UTC)

I should add that Dennis Ritchie co-developed Unix, primarily its I/O components. — DAGwyn (talk) 21:02, 12 December 2007 (UTC)

My C book tells me that "C was the language that was being written to write Unix in, and the developement of each had a strong impact on the other" (paraphrasing, can't find the book). Ofcourse, that may be really wrong, but that's what's roughly there. Martijn Hoekstra (talk) 21:07, 12 December 2007 (UTC)

Several versions of Unix were written (developed) before C existed, and the early Unix kernels were written in assembly language (first on the PDP-7, then on the PDP-11); see the history in the Unix article. The only general-purpose programming languages supported in the first edition of Unix were assembly language, B, a dialect of Basic, and a subset of FORTRAN. P. J. Plauger developed a "super-assembler" for the PDP-11 contemporaneously with Ritchie's development of C; both of these were meant to better support systems programming. B, which might have served in this capacity, had the problem of being entirely word-oriented, so it was unable to effectively exploit the PDP-11's byte-oriented features. As I mentioned previously, once data structures ("struct" types) were added to C (as it kept evolving), Ken decided to recode the Unix kernel into C. There is no doubt that due to the close proximity of these workers there was much interaction among them (as I noted previously); however, specific portions of the Unix environment were the responsibility of particular individuals, who made the design decisions and personally coded the products. Thus, C belonged to Dennis, and most of the Unix kernel (excluding I/O components) belonged to Ken. In "user space", the various commands, utilities, libraries, etc. belonged to various people; for example there were several early attempts at what eventually became the "standard I/O library"; one due to Mike Lesk, with Dennis providing the one that eventually prevailed. — DAGwyn (talk) 22:21, 12 December 2007 (UTC)

I will add that Ken was the original developer of the B language, but its role in the evolution of C starts with the B compiler that Dennis wrote; see the B article for more about the history. Much of C's syntax was inherited from B, and its influence is noted in the C article. — DAGwyn (talk) 23:32, 12 December 2007 (UTC)

Wow, thanks for all the infomation. Though not exactly what talkpages are meant for, it was a rather good read! Martijn Hoekstra (talk) 23:33, 12 December 2007 (UTC)

So what did Kernighan do ? Reg nim (talk) 18:17, 13 May 2008 (UTC)

Kernighan has written a number of books about C and Unix, including K&R. He also contriuted to Unix, including awk, nroff and troff. -- wrp103 (Bill Pringle) ^(Talk) 22:45, 13 May 2008 (UTC)

Many thanks. Reg nim (talk) 11:47, 14 May 2008 (UTC)

Closures?

In the section "Characteristics" is the phrase "function pointers allowing for a rudimentary form of closures and runtime polymorphism." I'm pretty certain that it's not possible to call these function pointers "closures." A closure (computer science) is defined as a function combined with a context or environment. Since C doesn't allow nested functions (extensions to the standard excepted), a traditional closure is not possible without trickery like (ab)use of the the preprocessor, or an explicit passing of variables to the function. I could be mistaken here, but I don't think so. I'd really like to change that sentence to be more correct. Any suggestions? Foolingmachine (talk) 03:22, 11 January 2008 (UTC)

It doesn't say that function pointers are closures, it says they can be used in implementing a rudimentary form of closures, which seems to be correct. It may also be necessary to employ static variables (corresponding to "bound" variables). I don't think there is any need to revise the wording. — 158.12.88.57 (talk) 18:07, 11 January 2008 (UTC)

That is true, and I see your point. I still think the wording could be revised, as it doesn't give any explanation of how this is possible, nor is this common knowledge (I'd venture that the majority of C programmers don't know what closures are anyway). Another issue I take with the phrasing is that I commonly see anonymous functions mistakenly called "closures." I don't want to further propagate that mistake. I do recognize I'm hardly an authority on the matter, of course. Foolingmachine (talk) 09:57, 12 January 2008 (UTC)

It is fairly common for OS or library APIs to allow the user to pass a callback function and a void* that will be passed to the callback when it is called. Most experienced C programmers will have seen one or more of those, even though they don't know that what they're doing would be called a "closure" if there were language support for doing it more transparently. It is not too far off to describe it as "a rudimentary form of closures", I think. Also it is not clear to me who you think the article supports the notion that closures means anonymous functions, when C does not have anonymous functions at all. –Henning Makholm 21:49, 12 January 2008 (UTC)

Again, fine points. From a functional programming standpoint, it simply seems highly odd that such a sentence is included with virtually no explanation whatsoever. It is not a common way to refer to C function pointers, even if the essential pieces are there (your void* could certainly be considered a method of passing the necessary context, but it's stretching the definition, I think). After all, none of the explanations presented on this talk page appear in the article. As for the "anonymous functions" bit, I wasn't very clear or correct—the bottom line is that closures are commonly misunderstood, and this phrase doesn't really provide any useful information. I can still see no valid reason to include it in the article, at least in the current form. Foolingmachine (talk) 03:14, 14 January 2008 (UTC)

I agree that it is strange for the sentence to be there; it would be better for the article to describe what function pointers are than to hint obliquely what they may be used for. (However, again, I don't think that the strange sentence claims that function pointers can be referred to as closures, only that they can be used as one of several building blocks for implementing closures. Don't you see the difference between those?) –Henning Makholm 03:24, 14 January 2008 (UTC)

As I recall, the bit about "closures" was already present before I started editing this article. I don't see the necessity to mention it, but presumably the original proponent had his reasons. — DAGwyn (talk) 05:10, 13 January 2008 (UTC)

I spotted this prior to reading this Talk and fixed it. The text really did seem to be claiming that function pointers are primitive closures. Though it's hard to pin down an exact definition of a closure, it has to do with the construction of a run-time object that encapsulates access to a captured lexical environment, plus code. C function pointers are the code only. You can't use C pointers to do closures, period; there is no standard-defined access to the lexical environment. Thanks to Turing equivalence, you can emulate the behavior, which isn't the same thing as expressing it. The page is already several times longer than a proper article, so there is no need to get into details about what features of other programming languages can or cannot be emulated using function pointers. A C example of emulating closures with function pointers might be appropriate in the Wikipedia page on closures, to which this article could point.

Relation of {} to set theory?

I always felt it is taken or inspired from here. It helped me to lear a C language (Anyway it is used for for example ordered set of statements, ordered set of "data structures" in declarations ... ). I recently ran into discussion that those 2 symbols have nothing to do with set theory. Could someone correct this? Xchmelmilos (talk) 22:33, 26 February 2008 (UTC)

In mathematics,

\{\}

are used for sets -

\{1,2,3\}

is the set containing 1, 2 and 3;

\{x\in \mathbb {R} \ |\ x>0\}

is the set of positive reals, etc.

In C however, braces are not used for sets, just compound statements and initializers, etc... but Oberon does use braces for sets (and BEGIN and END for blocks) and Pascal uses braces for comments.

Alksentrs (talk) 15:20, 28 February 2008 (UTC)

There is a kind of set-like use of braces in structure declarations, but really it is better thought of as a syntactic grouping construct than anything else, for C. —Preceding unsigned comment added by DAGwyn (talk • contribs) 17:34, 29 February 2008 (UTC)

The { } symbols can be used to define an array of elements (not a set) like this: int a[] = { 1, 29, 6 ,8 }; L337 Krew (talk) 13:43, 7 May 2008 (UTC)

Yes, that may have inspired their use in initializer lists, but not for compound statements. — DAGwyn (talk) 20:24, 8 May 2008 (UTC)

Also keep in mind that braced sets in modern math notation are unordered, whereas everything you put braces around in C is ordered, so this is a misleading analogy. There's certainly no basis for claiming C was designed with this analogy in mind. Dcoetzee 21:53, 8 May 2008 (UTC)

You're loony. C braces have next to nothing to with sets, semantically. I can't fathom what sort of learning difficulty with C could possibly be resolved by identifying braces with set notation. Gee, you know, I'm an astronomer. A double-pointer int (**x)(void) looks like a binary star system, which is something warmly familiar and helped me learn C ...

Archive 2 created

All the discussions had died off, and the page was way too long. — DAGwyn (talk) 00:38, 15 April 2008 (UTC)

I've gone through the archives and split them into reasonably-sized chunks. Thanks to the lack of housekeeping in the early days the first 4 pages or so are very poorly chronologically ordered (the very earliest discussion is on pages 3 and 4), but at least it's feasible to read through the old discussion now. I'll try to stay on top of this in future. Chris Cunningham (not at work) - talk 09:49, 1 May 2008 (UTC)

"Blather" and article introductions

So for the second time the tooshort tag was removed from the article with the addition of a "blather" which reads, in its entirety:

This article traces the evolution of C and describes its characteristics.

In addition, the summary for the edit made this observation:

The ToC serves just fine as a detailed article preview

This demonstrates a misunderstanding of WP:LEAD, and of the makeup and function of introductiory sections in Wikipedia articles in general.

Quoting from the summary of that style guideline:

The lead should be able to stand alone as a concise overview of the article. It should establish context, summarize the most important points, explain why the subject is interesting or notable, and briefly describe its notable controversies, if there are any.

The purpose of the lead section is not to serve as a foreword, or to describe in terms of the encyclopedia itself what the article is about. It is to serve as an effective summary and overview of the article's key points, such that reading the introduction provides one with a reasonable high-level understanding of the subject matter as if one had skimmed the article itself.

In this capacity, the current lead is inadequate. Beyond providing context (a literal description of what the article defines), it provides only one sentence to capture the importance of the language in its field. For an article of this length, we should be aiming for three paragraphs which provide a concise but complete summary of the article's key points without explicitly saying that the user has to read the article for further detail.

If we can't get this sorted out shortly, the article should be re-tagged so that it is adding to the appropriate cleanup category. That lets users interested in cleanup tasks know that there's work needed here. Chris Cunningham (not at work) - talk 10:57, 1 May 2008 (UTC)

The problem is, when in the past the lead included other (factual) "orienting" statements such as "C is one of the most widely used programming languages", proponents of other PLs (and critics of C) jumped all over it. The current lead is a compromise that was worked out long ago and it has remained very stable since then. It does perform the essential functions of a lead: it defines the subject, it explains its significance in the world, and it states the scope of the article. I see no point in trying to turn it into a "capsule article", since the text would become unintelligible if significantly abridged for that purpose. — DAGwyn (talk) 16:11, 1 May 2008 (UTC)

I could go either way. I think for C a short introduction is sufficient - but the current introduction surely understates the impact of C of both industry and research. As for critics of C "jumping all over it," I wrote the original criticism section on C and would still advocate an introduction emphasizing its impact. Dcoetzee 17:24, 1 May 2008 (UTC)

Thanks for the commentary. I suggest we work on an expanded introduction in this Talk page until a mutually acceptable version results. — DAGwyn (talk) 23:15, 2 May 2008 (UTC)

Update

I've done some minor expansion which provides a skeleton for further work. Chris Cunningham (not at work) - talk 12:49, 22 June 2008 (UTC)

Upper case

Mdsawyer58 has twice changed the identifiers in the original example

long int SomeFunction();
/* int OtherFunction(); */

/* int */ CallingFunction()
{
    long int test1;
    register /* int */ test2;

    test1 = SomeFunction();
    if (test1 > 0) 
          test2 = 0;
    else 
          test2 = OtherFunction();

    return test2;
}

to e.g. some_function on the grounds that "Historically, as stated by K&R in "The C Programming Language" manual (pg 33), uppercase is used for symbolic constants. I believe this page should be presented historically accurate." This reflects a couple of misunderstandings, which I will explain here in the hope of averting an editing war. K&R was talking about constructs like #define MAXLINE 80, where indeed all-upper case is used for a symbolic constant. That does not by any means imply that upper-case characters must not appear anywhere else in source code! It might be taken as implying that identifiers consisting solely of upper-case characters ought not to be used for anything other than symbolic constants. The above example does not violate any of these conventions. (Indeed, it illustrates a common and useful C style that is even more widely used in C++ and Pascal. It is good from the point of view of exposition to show that C identifiers, for variables and functions in this example, are not limited to lower case.) Note also that the example is valid as-is under the C compilers available at the time K&R was published, and was newly invented for this article. Therefore there is no error with regard to "historical accuracy." — DAGwyn (talk) 18:33, 11 July 2008 (UTC)

CSS

I noticed that CSS was added to the list of languages influenced by C in this edit. CSS is a markup language, and its syntax is quite different from C. Is there any reference to support the influence of C here? Papa November (talk) 18:31, 27 July 2008 (UTC)

I doubt it. I've removed it for now; we don't need to keep dubious information around while a reference is found. Chris Cunningham (not at work) - talk 19:49, 27 July 2008 (UTC)

Picture

What happened to the picture of the K&R C programming book in the summary box at the top of the page I didn't see it in the revisions at all --Melab ^±1 21:33, 9 September 2008 (UTC)

As I recall, somebody decided that it didn't meet Wikipedia requirements for photographic images, i.e. it wasn't copyright-free. — DAGwyn (talk) 00:04, 13 September 2008 (UTC)

Why is the 2nd edition shown, without mentioning earlier versions? I have the 1st edition (printed in 1978), as well as copies of the earlier "Reference Manual" which was an on-line file. (I also have some X3J11 notes, from when I was an Observer Member.) Should I try to include some of this stuff in Wikipedia? Tripodics (talk) 23:51, 29 March 2009 (UTC)

Howcome no syntax highlighting?

Not a very important point, but surely we should be using the <source lang="c"></source> tags in this article, otherwise why does Wikipedia have support for them? Was there a previous discussion on this? --Huffers (talk) 17:55, 27 September 2008 (UTC)

Ah, found it. I'm amazed people were against it. Given the most popular IDE's and text editors used for coding C all have syntax highlighting on by default, you'd have thought this would imply that most people find syntax highlighted code easier to read. --Huffers (talk) 18:08, 27 September 2008 (UTC)

Not everyone - it appears to be a preference rather than an absolute rule. It's been discussed several times (and see that there are several people to convince). Tedickey (talk) 18:41, 27 September 2008 (UTC)

Perhaps this article should have an editnotice to inform anyone editing it about the current consensus on source tags, so they don't keep getting put in and then reverted? Joseph Myers (talk) 20:05, 27 September 2008 (UTC)

While were on the subject, why is this exclusive to C? The same things could be said about most programming languages(if not all). Mike92591 (talk) 21:02, 27 September 2008 (UTC)

I'd suppose that making it a settable user preference would make more people happy with it - but look at the mess with dates, which are settable in principle. Tedickey (talk) 21:26, 28 September 2008 (UTC)

The main arguments against lang=c source tags are (a) the result looks horrible! in many browsers; (b) readability is actually reduced when more information is visually presented; (c) color is not part of the language; (d) such tags are of no value to a competent C programmer. For small code examples, whatever benefit is claimed for the coloration cannot be very significant anyway. — DAGwyn (talk) 10:38, 9 November 2008 (UTC)

Absent features

This really could go on and on. I think it would make more sense to just say what its features are. Mike92591 (talk) 20:17, 28 September 2008 (UTC)

Actually the list is a meager remnant of the now-vanished Criticism of C (programming language) article. It serves a useful purpose under the section on Minimalism. — DAGwyn (talk) 10:41, 9 November 2008 (UTC)

operators

operators explain in c language —Preceding unsigned comment added by 164.100.6.50 (talk) 10:24, 7 October 2008 (UTC)

I guess you're looking for Operators in C and C++. Alksentrs (talk) 11:43, 7 October 2008 (UTC)

Somebody removed the section that listed them, which I have now restored (it contains the link mentioned above, which goes into more detail). — DAGwyn (talk) 10:46, 9 November 2008 (UTC)

Added first line

i added first line because the first line is very well not a good beginning. The beginning should be an introduction to comp language C.Albertgenii12 (talk) 21:16, 21 October 2008 (UTC)

"Array types in C are always one-dimensional"

Surely this is just wrong. I just wrote a little program to check I wasn't going mad and prove that you can have 2+-dimensional arrays in C. And it works:

[BTW No-one need bother pointing out the lack of variable initialisation!]

#include <stdio.h>

typedef char array[10][10];

void main(void)
{
array test;
int x,y;

for (x=0; x<=9; x++)
{	for (y=0; y<=9; y++)
		printf("%3d ",test[x][y]);
	printf("\n");
}
}

RobertSteed (talk) 16:30, 18 November 2008 (UTC)

Read a bit further down. "C does not have a special provision for declaring multidimensional arrays, but rather relies on recursion within the type system to declare arrays of arrays, which effectively accomplishes the same thing. The index values of the resulting "multidimensional array" can be thought of as increasing in row-major order." I'm skeptical about this interpretation, but without carefully consulting the standard I'm not prepared to contest it. Dcoetzee 21:29, 18 November 2008 (UTC)

I did read that, and it too is wrong. Again, see my example - that is a multidensional array, in standard C code. It is not an array of arrays.

RobertSteed (talk) —Preceding undated comment was added at 11:26, 19 November 2008 (UTC).

Your example is wrong.

That is an array of arrays.

Consider what sizeof test[x] means. —Preceding unsigned comment added by 216.239.45.4 (talk) 11:41, 1 March 2009 (UTC)

It is a matter of interpretation. However often used, an array in C is veneer ("syntactic sugar)" over plain pointer arithmetic. The way it handles multidimensional arrays is to extend that pointer arithmetic. So, in fact, C does not have any special provision for multidimensiaonal arrays. However, as far as I'm concerned, the same could be said for one-dimensional arrays in C. I see no point in the statement saying "they're always one-dimensional". I'm for deleting that. --A D Monroe III (talk) 12:11, 19 November 2008 (UTC)

Me too - you might as well say C doesn't really have array indexing, since it's just syntactic sugar for pointer arithmetic and dereferencing. It was designed to support multidimensional arrays in this way. Dcoetzee 20:40, 19 November 2008 (UTC)

The array indexing operator [] is just veneer over pointer arithmetic. Arrays themselves are not. Eric119 (talk) 00:25, 20 November 2008 (UTC)

Eric119 is right; and furthermore, the fact that C arrays are inherently one-dimensional is important for a programmer to understand, as it affects function parameters (for example). — DAGwyn (talk) 17:53, 6 May 2009 (UTC)

As a side note, it is important to see that there is a difference between a 2 dimensional array like char arr[10][10] (which does rely on recursion), and a 2 dimensional array where the first dimension is an array of pointers to the second dimension. A good example of the latter is argv (the 2nd argument to main, the argument vector). The simple 2 dimensional uses less memory, and is generally consecutive in memory - the second uses more memory (the size of the first dimension) and may or may not be consecutive in memory Ajrisi (talk) 13:01, 12 May 2009 (UTC)

POV-based comments regarding object-orientation

The C language doesn't provide built-in support for object-oriented code (nor in fact for several interesting features), though those can be constructed. There are well-known examples of class-structures in C, e.g., X Window System. It would be nice to reduce the persistent intrusion of POV-based edits in this area. Tedickey (talk) 20:06, 11 December 2008 (UTC)

I did not edit any of the article in regard to this area, but I don't agree with you. The current version of the article says: Very limited support for object-oriented programming with regard to polymorphism and inheritance. There is no built-in support at all, I would prefer a sentence like: No built-in support for object-oriented programming. This would be more accurate IMHO. It's the same for generic programming. With C you can do anything you want (C is a very powerful general purpose low-level language), but as C is intentionally "close to the metal", you doin't have much help for any high level constructs such as Object Oriented Programming, Generics, Closures, Garbage Collection, etc... It does not mean that you can not develop frameworks in C to support these features. Hervegirod (talk) 12:51, 17 January 2009 (UTC)

open standard

It is kind of curious to see C# in the open standard article, but not C.

Is there a reason for that ?

If not, could someone who knows a bit about the subject add it there ?

Current C standards apparently don't meet the criteria. Generally, you have to buy a copy, and that's cheaper for some national-body versions than for others. I don't know whether the next C standard (C1x) will qualify as an "open standard." — DAGwyn (talk) 17:58, 6 May 2009 (UTC)

Image copyright problem with File:Kr c prog lang.jpg

The image File:Kr c prog lang.jpg is used in this article under a claim of fair use, but it does not have an adequate explanation for why it meets the requirements for such images when used here. In particular, for each page the image is used on, it must have an explanation linking to that page which explains why it needs to be used on that page. Please check

That there is a non-free use rationale on the image's description page for the use in this article.
That this article is linked to from the image description page.

This is an automated notice by FairuseBot. For assistance on the image use policy, see Wikipedia:Media copyright questions. --13:49, 8 February 2009 (UTC)

Pointer alignment

Regarding my addition reverted in rev. 274795659, is not the reference to the WG14 year 2005 draft of the C standard sufficient to substantiate my re-phrasing of the actual paragraph 7 of section 6.3.2.3? --ilgiz (talk) 23:55, 3 March 2009 (UTC)

The editor who reverted seemed to think that your description was not faithful to the standard.

It is difficult for me to understand your paragraph; you say that the C standard requires such-and-such, but it is not clear whom it requires it of. Is it something a C implementation must make sure happens, or something a programmer must construct his program to conform to? It's not easy to tell from your text, unless one already knows what you're trying to say.

Also, it is not clear to me that the issue is one that ought to be discussed in this article at all. It is not my any measure a central property of the C programming language how it deals with unaligned pointer casts. Language lawyers and professional programmers who care about the theoretical limits of portability need to know these things, but they need to know many more details than a general encyclopedia article can reasonably provide anyway. Everyone else will probably go "huh?" no matter how well this is explained. –Henning Makholm (talk) 01:06, 4 March 2009 (UTC)

I read your comment as a concern that it is up to the C compiler implementation to go into necessary details of targeted CPUs. But I think the standard had to be adjusted so that it would apply universally. You may already know that some CPUs require word access to occur by an aligned boundary and that the compilers targeted to such CPUs provide ways to adjust the code to the CPU specifics. For example, armcc offers the following measures:

stack variable alignment on a boundary of multiple of 8,
the __packed qualifier that would make the compiler access adjacent words and combine them into a result,
the __align(n) keyword that forces alignment on a multiple of "n".

I think that following the pointer alignment restriction I found in the C standard draft would allow to write portable code. For example, to make the anti-example portable,

char *external_buffer = "abcdef";
uint32_t *internal_data;

internal_data = (uint32_t *)external_buffer;  // UNDEFINED BEHAVIOUR if "the resulting pointer is not correctly aligned"
// Also, *internal_data results in different values on big- and little-endian CPUs.

I would write:

char *external_buffer = "abcdef";

// Apparently, it goes without saying that automatic and static variables are guaranteed to be correctly aligned
uint32_t internal_data1;
uint32_t *internal_data = &internal_data1;

// Alternatively, section 7.20.3 "Memory management functions" guarantees that malloc() returns an address of a super-aligned block
// uint32_t *internal_data = malloc(sizeof(uint32_t)); 

// assuming the network order of the external data and that the protocol stipulates a 4-byte field in the beginning
*internal_data = (((((uint32_t)(external_buffer[0]) << 8) | external_buffer[1]) << 8) | external_buffer[2]) << 8) | external_buffer[3];

It is good that the article can be an educational material. I do not mind if it also presents minor details reflected in the C standard. --ilgiz (talk) 16:12, 4 March 2009 (UTC)

I think there are several misconceptions in the above. The C standard does not currently include any specific object-alignment aids, and implementations are always required to align the standard types so that they work (which is one reason structs can have internal padding).

It is certainly true that a few target-specific applications need some additional form of alignment control, for example aligning DMA buffers with memory cache lines; in such cases, compilers for those targets virtually always provide nonstandard extensions to do the job.

Alignment of word pointers on sub-word boundaries cannot be supported on many platforms without a high run-time cost for using that facility, and since it is rarely useful (only for picking fields out of a packed record image, which may also have endian issues) the C standards committee has been reluctant to require it be supported by all implementations. — DAGwyn (talk) 18:10, 6 May 2009 (UTC)

Re: "in such cases compilers for those targets virtually always provide _nonstandard_ extensions to do the job", I only touched on the case when a programmer casts a pointer of granularity 1 to another pointer of higher granularity. I suggested that this often stems from unawareness of the C compiler varieties and targets and of the C standard's section 6.3.2.3, par. 7 that prohibits such casts. I suggested that the cast should be replaced by allocating a properly aligned buffer of the higher granularity and by populating its content. Optionally, I suggested that it might make sense to combine the content transfer with the network-to-host order conversion.

Re: aligning hardware buffers, I am not experienced with this much. If the problem is in creating a buffer with a certain granularity that exceeds the particular C compiler/target's notion of super-alignment in malloc(), it is still possible to allocate a sufficiently large buffer and calculate the low and high addresses satisfying the required granularity. This would keep the code C standard compliant as it would not depend on non-standard keywords.

Re: impossibility of casting "sub-word" addresses to "word" pointers within C standard, this agrees with the above reference to section 6.3.2.3 par. 7. I understand that certain compilers do provide non-standard keywords such as __packed that tell the compiler to generate 2 word accesses, combine the results into one temporary word by rotating/masking these results and resolve *wordP into that temporary word. I am just saying that instead of relying on non-standard features and C preprocessor branching by target, it is possible to write portable bare C code by picking "sub-words" explicitly and putting them into a "word"-aligned buffer. --ilgiz (talk) 22:17, 8 May 2009 (UTC)

"C has a formal grammar"

If the "printed copy" referred to by the description of rev. 281338283 is the "Annex A (informative): Language syntax summary" section of the current standard WG14/N1256, one could mention that section as a reference. I guess the formal grammar does not define the language, its environment and its library, but only serves informative purpose. --ilgiz (talk) 19:16, 2 April 2009 (UTC)

It takes more than a grammar to define a programming language. C does have a formal grammar, but so does virtually every PL. The grammar in the Annex of the standard is derivable from the specifications scattered through the body of the standard. — DAGwyn (talk) 18:15, 6 May 2009 (UTC)

C# not mentioned as related

I don't want to edit this, in case the consensus is that it is too far removed, but I believe C# is based on C++ therefore should be mentioned as a "related language" to C, which started it all. The C# article does say this.KoolerStill (talk) 11:17, 23 April 2009 (UTC)

Huh? "C has directly or indirectly influenced many later languages such as Java, C#, Perl, PHP, JavaScript, LPC, and Unix's C Shell." Chris Cunningham (not at work) - talk 11:58, 23 April 2009 (UTC)

no link to C functions list??

There is a List of C functions with a separate article on each function. I can't see a link to this from this article. Is this deliberate? or is the list destined for deletion? I think it might be a little too detailed for an encyclopedia, but if it is there it should be linked to the main article on the language.KoolerStill (talk) 11:58, 23 April 2009 (UTC)

There are some well-established standard C library functions (currently subsetted for standalone implementations). Beyond that, there are C interfaces to other functions with varying degrees of standardization, and most programmers need to use some of them too. Since the page you mentioned mixes these together, and has many broken links, it doesn't merit inclusion as a reference here. The C article should no more be a master link page for everything related to C than the Oxygen article (if there is one) should link to articles about everything containing oxygen. — DAGwyn (talk) 18:22, 6 May 2009 (UTC)

That's partly why I was wondering about the usefulness of that list. Being a list, it offers no explanations, not even of what library function are. Yet in the article, where that is explained, there is no reference to the list, so the list seems to be orphaned. And more appropriate to a programming handbook than an encyclopaedia. Maybe I'm on the wrong talk for this concern? KoolerStill (talk) 20:41, 8 May 2009 (UTC)

Imperative vs. procedural

In the infobox next to “Paradigm,” C is tagged as being an “imperative (procedural)” programming language. Why are these two attributes not listed separately and independently (i. e., simply separated by commas, rather than one being in parentheses)? Does being either necessarily imply the other, or, conversely, is it impossible to be one but not the other? I’m not a programming language expert, and therefore would like clarification from one of the article’s authors. Thanks! —Technion (talk) 16:36, 2 May 2009 (UTC)

A procedural language is a particular kind of imperative language. Another would be an OOP language (in the C++/Java style). Alksentrs (talk) 16:45, 2 May 2009 (UTC)

According to the Wikipedia article on “Structured programming,” structured programming can also be considered a subset of procedural programming, and yet the tag “structured” is written independently, separated by a comma; according to your logic, the tag would then have to be double-parenthesized and written as “Paradigm: imperative (procedural (structured)).” Why the inconsistency? —Technion (talk) 17:01, 2 May 2009 (UTC)

Interesting point... I think that whilst you can use structured programming in C, it wasn't specifically designed for only structured programming: it has the goto statement, for example. Alksentrs (talk) 17:33, 2 May 2009 (UTC)

The definitions here are quite vague. I was taught in the end of 80's that procedural languages specify algorithms (the procedures leading to results), while non-procedural languages specify goals (SQL and Prolog, for examples, unless you delve deeper into SQL procedural extensions or use Prolog in procedural style). From my point of view, the situation is quite the opposite: Imperative languages (those based on visibly modifying a global state in the course of a computation) are a sub-group of procedural languages. But as I said, the definitions are quite vague. 85.70.62.27 (talk) 17:26, 7 June 2009 (UTC)

Enum deficiency

Without resorting to X-Macros, a C programmer cannot loop across enum values. In the best case, when the minimum and the maximum values for the enum are known and when there are no holes in the definition, a regular for loop will result in a warning that the condition is always true. I wonder if this may theoretically cause a run-time exception or lock-up with C implementations that insist on enum value consistency.

  e_t evar;
  for (evar = e_first; evar <= e_last; evar++) {
    ...
    continue;
    ...
  }

This best-case scenario could probably be rewritten as follows.

  e_t evar;
  for(evar = e_first; ; evar++) {
    ...
    goto next;
    ...
  next:
    if (evar == e_last) {
      break;
    }
  };

--ilgiz (talk) 21:35, 4 May 2009 (UTC)

Please use this page only to discuss possible edits to the C article, not for programming issues. The C "enum" facility was never meant to provide a compact set that can be iterated over. It was really meant as an alternative to #defined constant names as values of tag fields, and that was largely because it was nicer when using some (really old) debuggers, which would display the names for enum constants but not for cpp macros. — DAGwyn (talk) 18:30, 6 May 2009 (UTC)

This is almost true. The enum facility is an alternative to macro constants, but additionally provides a way of bounding acceptable values. For example, a function that takes an enum type as an argument enforces passing only values that are part of the enum, in comparison to a function that must take an int (or long, or whatnot) because the macro is typeless. Ajrisi (talk) 13:00, 12 May 2009 (UTC)

While it is not necessarily good practice to iterate across an enum (because enum values are not always consecutive), a common way of doing it is to have the last value in the enum be something like "MY_ENUM_END" (with MY_ENUM being changed to something more specific). Once that has been done, its fairly easy to use a common 'for' loop. Your code above (2nd part), by the way, is exactly the for loop:

  for(evar = e_first; evar != e_last; evar++) {...}

Remember, whenever possible, avoid goto's like they are the plague. Ajrisi (talk) 13:00, 12 May 2009 (UTC)

Thanks, ajrisi. Your correction is much shorter but needs to change the enum definition as you mentioned. Going back to my notation, your correction requires adding an artificial boundary element e_past_end to the enum definition, so the condition should look like evar != e_past_end. One cannot get by just writing evar != e_last + 1 as (a) I am not sure about C standard's limitations on arithmetic operations with enum values and (b) e_last + 1 might theoretically cause a run-time error. --ilgiz (talk)

Spot on - I left it as e_last, assuming that would be his name for what I called MY_ENUM_END. as for != e_last +1, you could do that, if you were sure that the enum values were consecutive, and that e_last+1 did not occur earlier in the list. Here is an example that the e_last + 1 would have trouble with:

 enum {
   E_FIRST = 0,
   E_SECOND = 2,
   E_LAST = 1
 };

You can see that the code would prematurely quit when it did the (evar != E_LAST+1). While it certainly wouldn't meet any form of coding standards, you always have to think "it could happen". Oh, before I forget, enums are internally stored as integers in the C standard (ISO/IEC 9899:1999 6.7.2.2 - The expression that defines the value of an enumeration constant shall be an integer constant expression that has a value representable as an int ) Ajrisi (talk) 13:00, 12 May 2009 (UTC)

I made a couple of changes to the above convo., changing the anonymous edits to show they were written by me. I did indeed write them, I just wanted people to know who to blame later if I was wrong. Thanks - Ajrisi (talk) 13:00, 12 May 2009 (UTC)

why not lang="c"?

Hidden editor comment in article: "Also, present consensus is against lang="c". " May I ask why? Isn't syntax highlighting a good thing? I can see turning it off for the outdated K&R example, but why is it off for the normal "Hello World!" example? --Cybercobra (talk) 23:57, 10 May 2009 (UTC)

Past discussions:

Alksentrs (talk) 01:46, 11 May 2009 (UTC)

Personally, I don't like syntax highlighting but, those really aren't good reasons. Mike92591 (talk) 21:17, 11 May 2009 (UTC)

Agreed. It's time to re-think this. If the lang attribute results in poor presentation in certain conditions then that should be brought to the attention of the MediaWiki developers, not hacked around on one of our highest-profile programming language articles. It's there for a reason, and we should use it to provide the greatest semantic value for our readers. Unless there are any new and more valid objections than "it sucked in 2007" and "we agreed that it sucked in 2007" then I'd be happy with adding the lang parameter back. Chris Cunningham (not at work) - talk 14:40, 19 May 2009 (UTC)

Syntax highlighting is great as a personal preference in one's own editor where you can customize it and turn it off (Lord knows I always use it), but it really doesn't have a place in a general purpose, entry level article. - Richfife (talk) 17:41, 19 May 2009 (UTC)

That's a different debate. The question here is not whether or not the <source> tag should have syntax highlighting, but why we're not using the <source> tag's lang attribute to properly mark up source code when that's what it's provided for. If editors disagree with syntax highlighting then they should be arguing with the MediaWiki developers to turn it off on Wikipedia's deployment, not hacking around it by not marking up code correctly in articles. Chris Cunningham (not at work) - talk 15:20, 20 May 2009 (UTC)

Not really. Mediawiki can decide whether or not to provide it, but the decision to USE it is an article to article (or, more likely, a wiki to wiki one). The software is used on many wikis, so the presence of a particular feature doesn't imply it should be used everywhere possible. - Richfife (talk) 19:03, 20 May 2009 (UTC)

I said "on Wikipedia's deployment". Would you agree that if the Wikipedia instance of MediaWiki has syntax highlighting turned on, that this is an implicit endorsement of the use of this feature on Wikipedia articles? Chris Cunningham (not at work) - talk 01:51, 21 May 2009 (UTC)

No, I wouldn't. Making a particular feature available in the underlying software is not an editorial decision. It's a "here it is. You decide if you want to use it" decision. The maintainers of the media wiki software and the people that decide which features to include in an instance have no more editorial decision making power than you or I. - Richfife (talk) 20:12, 21 May 2009 (UTC)

Update

Seeing as there hasn't been any real pushback on this, I'm going to turn syntax highlighting on again. Most of our high-profile programming language articles use it now, so the inconsistency here doesn't seem to be warranted. Chris Cunningham (not at work) - talk 10:51, 3 July 2009 (UTC)

At the very leasti, I think someone should fix the ridiculous choices of colours first. Yellow on gray background is not really "highlighting", more like hiding. — Miym (talk) 14:11, 3 July 2009 (UTC)

That should be brought up with the MediaWiki developers. I have no idea why people think that using this article as a proxy for getting these things changed is a good idea; all it does it reduce the quality of this article. Chris Cunningham (not at work) - talk 14:23, 3 July 2009 (UTC)

Pushing back. Current consensus, which I agree with, is no. I've never seen a book or online C resource use syntax highlighting and unless there's a defined user by user method in preferences of customizing it or turning it off, it's a bad idea. Also, as I mentioned above, MediaWiki and this article are two separate things. The presence of a feature in the software is not an endorsement of its use any particular article. Until syntax highlighting is added to a programming standard and is not an ad-hoc, after the fact creation, it should be kept out of the articles. - Richfife (talk) 14:54, 3 July 2009 (UTC)

Again, that is using this article as a proxy for a personal disagreement with a development decision. This does nothing to improve the software, but does make this article incongruous with those programming language articles which aren't being watched by editors who disagree with said development decision. Chris Cunningham (not at work) - talk 17:27, 3 July 2009 (UTC)

Development decision != editorial decision. No relation whatsoever. The developers of mediawiki do not dictate the use of features available in articles. Why is that so hard? This was discussed 2 years ago: Talk:C_(programming_language)/Archive_8#Source_language_.3D_C_formatting. Have you tried syntax highlighting with all the Wikipedia skins yet? Have you tried it with all browsers? - Richfife (talk) 19:25, 3 July 2009 (UTC)

Also, the problem with trying to "fix" the software is that there IS no right solution to the problem. Everything is going to look bad somewhere. - Richfife (talk) 19:37, 3 July 2009 (UTC)

C programmers need more care ?

The section on syntax about operator evaluation includes the following sentence: "This permits a high degree of object code optimization by the compiler, but requires C programmers to exert more care to obtain reliable results than is needed for other programming languages." Many other languages don't actually specify an order of evaluation for operands, so I would have thought C's approach was far more reliable. I propose that the sentence be truncated to ""This permits a high degree of object code optimization by the compiler." Any objections ? Cadae (talk) 07:11, 27 June 2009 (UTC)

The sentence quoted is not only referring to "order of evaluation", it is also (and perhaps more significantly) referring to the fact that "The evaluations may even be interleaved." Chris Burrows (talk) 12:43, 27 June 2009 (UTC)

In some other languages the presence or absence of interleaving is not even specified (e.g. Pascal) - again the explicit definition in C (that there could be interleaving) is safer than the situation in some other languages. The problem is that the issues vary by language - C# and Java specify an explicit operand evaluation order so sequencing and lack of interleaving are clearly defined, whereas Pascal, Ada, C, C++ and some others don't specify an order of evaluation for all operands. It is therefore inaccurate to say that C programmers have to exert more care than is needed for other programming languages. Perhaps more care than for Java or C#, but not more care than, for instance, Pascal. Cadae (talk) 10:43, 28 June 2009 (UTC)

c language

why calling c language is middle level language —Preceding unsigned comment added by 59.164.2.104 (talk) 15:24, 10 August 2009 (UTC)

Revised ISO/IEC 9899 Committee Draft

JTC1/SC22/WG14's ISO/IEC 9899 page states "The most current draft of the revised C99 standard is available in N1336." Update to links section required. - 204.111.152.29 (talk) 02:34, 19 October 2009 (UTC)

constant pointers

hi,

my question is about constant pointer

Can you make a constant character pointer point to some other string —Preceding unsigned comment added by 122.167.74.225 (talk) 14:26, 20 October 2009 (UTC)

Not really the place for this, but... It depends on where the const is. The const applies to whatever immediately follows it. You can change "const char *" to point to a different string, but you can't change the contents of the string memory it points to. You can not change what memory "char const *" points to, but you CAN change the contents of the memory. "const char const *" menas you can do neither, but some compilers (*cough*microsoft*cough*) emit a bogus warning on that declaration. - Richfife (talk) 16:36, 20 October 2009 (UTC)

"const char *p" = "char const *p" = non-constant pointer to constant char. However, "char * const p" is something different: a constant pointer to non-constant char. And "const char * const p" is a constant pointer to constant char. (Easier to remember if you read these "backwards": "char * const p" = "p is a const pointer to char".) — Miym (talk) 18:47, 20 October 2009 (UTC)

Generic programming completely absent

The article says:

Only rudimentary support for generic programming

despite being a C programmer that have abandoned C++ for the PODs issues, I must say there is no generic programming whatsoever in C, unless the preprocessor is counted; and since the preprocessor provides no type control whatsoever, counting the preprocessor is not justified. ... said: Rursus (bork²) 10:43, 17 January 2009 (UTC)

It does support a limited form of generic programming with generic pointers; qsort is a good example. Mike92591 (talk) 21:09, 17 January 2009 (UTC)

qsort is not an example of generic programming, rather of first-class functions implemented using function pointers. Adrianwn (talk) 06:44, 6 March 2010 (UTC)

Comma operator links to sequence point?

Under "Operators", there's a group "sequencing" containing only the comma operator, which links to the Sequence Point page. Is this right? While the comma operator is certainly a sequence point, that does not appear to be its primary purpose. From K&R:

Comma operators should be used sparingly. The most suitable uses are for constructs strongly related to each other, as in the for loop in reverse, and in macros where a multistep computation has to be a single expression.

--Mcaruso (talk) 20:44, 24 May 2009 (UTC)

The only functions of the comma operator are to insert a sequence point, and to separate subexpressions for convenience in contexts where multiple things are going on, such as for(p=base,i=0;i<MAX;++p,++i) and if(++p,++i>=MAX). There isn't any name or Wikipedia page for "programming convenience", but there is for "sequence point". — DAGwyn (talk) 02:46, 24 July 2010 (UTC)

Guidance asked for some details about my recent edit

The "minimalism" paragraph talks about the relative ease of implementing compilers that generate efficient machine code, and cites the DEC PDP-11 as a case in point. To expand on the intent of the paragraph I added mention of C compilers for some 8-bit platforms, linking to one that has a Wikipedia page. My two questions are:

1. While the PDP-11's CPU is also 16 bits, the original article seems to stress its 16-bit address space, not the CPU itself; apparently the intent is to stress the compactness of the generated object code as well as access to arbitrary addressable objects. However, the ability to compile efficient object code for simpler CPUs with far less sophisticated instruction sets also testifies to this point. Reading over my edit, though, it seems the juxtaposition of text stressing address space in one case and CPU data size in the other seems possibly confusing. Does anyone have an opinion on this?

2. I am only aware of one such compiler (Aztec_C). My first shot at the sentence said something like, "There is at least one..." That looked awkward, so I changed it to simply "Compliers for..." I can't say with certainty if the plural is actually correct. Does this matter or can the plural wording be considered to be generic and covering both cases?

Rhsimard (talk) 23:21, 19 September 2009 (UTC)

The context was intended to be the compilation environment, not the run-time target, and the initial C implementations were for the PDP-11, which has an address space comparable to the 8-bit platforms that ran Aztec C and ORCA C. Those compilers did not fully implement C89, largely due to size limitations, and fully compliant C99 versions would have to be highly segmented, making them impractical. I have just fixed up the wording to make it clearer. — DAGwyn (talk) 03:01, 24 July 2010 (UTC)

Why C weakly typed?

No matter what source i look at, everything tells me that C is strongly typed. So why not? 81.182.51.168 (talk) 15:07, 14 December 2009 (UTC)

See "casting" - in a strongly typed language, casting is not possible —Preceding unsigned comment added by 192.91.172.42 (talk) 18:34, 14 December 2009 (UTC)

Huh? Yes, it is. The difference is, that a strongly typed language will check the cast for validity at run time or (if possible) at compile time. For example, Java lets you cast a reference of type A to a different type B. If the referenced object does not support type B, an exception will be thrown (or the compiler will report an error). In C, you can cast a pointer-to-int to a pointer-to-float, and no exception will be thrown. Adrianwn (talk) 17:09, 19 December 2009 (UTC)

Yes, casting is possible in even strongly-typed languages, but that's not the issue. "Strongly typed" means that object types are semantically enforced, so that you can't do things like assign a struct pointer to a float variable. The language specifies these typing errors as constraint violations, which is what makes C a "strongly-typed language". Explicit typecasting is way to turn off the built-in strong type checking. — Loadmaster (talk) 19:29, 29 December 2009 (UTC)

I think you're confusing "strongly typed" and "statically typed": those constraint violations that you mentioned are due to the static types of the variables you use. This static type check can be easily circumvented, even without casts. Example:

        int a;
        float b;
        void* p = &a;
        float* q = p;
        b = *q;

This will compile without errors or warnings, making C a weakly typed language — a strongly typed one will either not allow this, or throw an exception at runtime. C can't even be strongly typed, because it has a weak type system and lacks any concept of "objects" and associated type information at runtime. By the way, I found an excellent explanation here: Is C strongly typed?. Adrianwn (talk) 09:28, 30 December 2009 (UTC)

I'll concede the point, but it should be noted that those kinds of conversions are only allowed for conversions to and from void pointer values. Assigning a float value to a pointer, for example, is illegal. — Loadmaster (talk) 19:06, 1 January 2010 (UTC)

websites can also be programmed in C

CGI programming in C never mentioned in the entire article.

1.) Tons of "ink" in the web about which Interpreted language is better for websites... what about C/C++/Java ?

2.) High volume websites use C/C++/Java in critical areas (for speed).

3.) C not only for system and application programming (as Uses section suggests).

Discuss possible new section... and update of "Uses" section ? 83.55.41.191 (talk) 21:38, 4 January 2010 (UTC)

Of course C can be used for any kind of computer programming, including implementing web sites. I don't think it makes any sense to try to list all possible uses. I'd prefer if we just mentioned the most typical uses. — Miym (talk) 21:59, 4 January 2010 (UTC)

I agree with Miym, although to be honest I don't feel all that strongly about it in this case. Any Turing Complete language can be used to do anything (and probably has been). - Richfife (talk) 23:37, 4 January 2010 (UTC)

Stuff removed from Boolean data type article

The following section was removed from the article Boolean data type:

begin removed text
To this day, Boolean values are commonly represented by integers in C programs. The comparison operators (' > ', '==', etc.) are defined to return a signed integer (int) result, either zero (for false) or nonzero (for true). The Boolean operators (&&, ||) and conditional statements (if, while) in C operate on integer values, with the same interpretation. For example, the following C code

int t = (x > y);
if (t) { printf("True!\n");} 
else { printf("False!\n"); }

is equivalent to

int t;
if (x > y) { t = -1; }
else { t = 0; }
if (t != 0) { printf("True!\n"); }
else { printf("False!\n"); }

However, since the C language standards allow the result of a comparison to be any non-zero value, the statement if(t==1){...} is not equivalent to if(t){...} or to if(t!=0){...}.

Since C standards mandate that 0 be interpreted as the null pointer when used in a pointer context or cast to a pointer, one can test whether a pointer is non-null by the statement if(p){...} instead of if(p!=NULL){...} — although some code styles discourage this shorthand. One can also write if(x){...} when x is a floating-point value, to mean if(x!=0){...}.

For convenience, many programmers and C header files use C's typedef facility to define a Boolean type (which may be named Boolean, boolean, bool, etc.). The Boolean type may be just an alias for a numeric type like int or char. In that case, programmers often define also macros for the true and false values. For example,

typedef int bool;
#define FALSE 0
#define TRUE (-1)
...
bool f = FALSE;
...
if (f) { ... }

The defined values of the TRUE and FALSE macros must be adequate for the chosen Boolean type. Note that, on the now common two's complement computer architectures, the signed value -1 is converted to a non-zero value (~0, the bit-wise complement of zero) when cast to an unsigned type, or assigned to an unsigned variable.

Another common choice is to define the Boolean type as an enumerated type (enum) allows naming elements in the language of choice. For example, the following code uses the English names FALSE and TRUE as possible values of the type boolean. In this case, care must be taken so that the false value is represented internally as a zero integer:

typedef enum { FALSE, TRUE } boolean;
...
boolean b = FALSE;
...
if (b) { ... }

Again, since a true result may be any non-zero value, the tests if(t==TRUE){...} and if(t), which are equivalent in other languages, are not equivalent in C.

end removed text

The discussion above is wrong to say the comparison operators return either zero (for false) or nonzero (for true). A true result is not defined as any non-zero value in C - it is defined as 1. Logical expressions are defined to have value 1 if true and value 0 if false. When testing an expression, non-zero is regarded as true, 0 as false. In other words, res = a > b; (where all variables are of type int) is guaranteed to assign either 0 or 1 to res; however, if x contains 27, if (x) will evaluate to true. Also, the use of the word result is being used in a confusing way. - Mickraus (talk) 16:16, 1 February 2010 (UTC)

Is there a place for this text in the C-related articles? Perhaps in the Wikibook? Thanks, and all the best, --Jorge Stolfi (talk) 23:28, 30 December 2009 (UTC)

First program to use Hello, World

According the following wiki page the original "hello, world" was written in BCPL, the grandfather of C. Although it is marked as "citation needed". However this article has no citation for C to be the first program. --Lindy (talk) 09:46, 1 February 2010 (UTC)

This article says something different (which is sourced) Tedickey (talk) 09:52, 1 February 2010 (UTC)

In section: "Hello, world" example, printf is subject to Format String Attack

Original:

printf("hello, world\n");

Modify to:

printf("%s", "hello, world\n");

The "%s" must be included to avoid a Format string attack. Please, discuss... 83.55.41.191 (talk) 21:38, 1 January 2010 (UTC)

After reading that article and a cursory glance at this, I believe the vulnerability is present only when you pass "unfiltered user input" directly to these functions as format strings, as in printf(buffer); where the string buffer gets its value during runtime by user input. In the case of "hello world\n", the simple string "hello world\n" is constant, doesn't contain harmful characters and cannot be altered by user input; so its safe. Instead of "hello world\n" were it the string "%s%s%s%s%s%s%s%s%s%s%s%s", the program would crash (this particular example is from the pdf linked above). --Zvn (talk) 22:36, 1 January 2010 (UTC)

I have not read the linked page but the point is fairly obvious to hard core coders. There is clearly no problem with the current article, and I do not think we need be concerned with providing a full set of best practices, so I do not think any change is needed. Johnuniq (talk) 03:54, 2 January 2010 (UTC)

Agreed. This is not the place for this. - Richfife (talk) 06:01, 2 January 2010 (UTC)

One should also realize the context in which that example was given. It is like showing someone how to drive a car: in a supermarket parking lot, not a lot of care is given for staying on the correct side of the road but merely keeping the hands on the steering wheel. Same here: hello.c is to show how to put things on the screen, not how to be 100% correct. 118.90.14.223 (talk) 09:43, 1 March 2010 (UTC)

Zvn is correct. There is absolutely no problem with the code. Eric119 (talk) 17:30, 2 March 2010 (UTC)

16-bit longs?

Anybody ever heard of a 16-bit long? Specifically, in some old 16-bit version of Visual C++? See Talk:Long integer#16 bits???. —Steve Summit (talk) 13:33, 21 April 2010 (UTC)

As I recall, all versions of Microsoft C/C++ (later called Microsoft Visual C/C++) had 32-bit longs. If there were such a compiler, it would not be ISO-compliant, which requires long int to have at least 32 bits. — Loadmaster (talk) 21:19, 21 April 2010 (UTC)

And the (dubious) claim in question has been deleted. [2] —Steve Summit (talk) 12:37, 24 April 2010 (UTC)

Backwards syntax

Stated as a weakness: "Similarity of the assignment and equality operators (= and ==), making it easy to accidentally substitute one for the other. C's weak type system permits each to be used in the context of the other without a compilation error (although some compilers produce warnings). For example, the conditional expression in if (a=b) is only true if a is not zero after the assignment"

One text I read suggested a way to avoid this error: Keep a constant to the left of a variable. Whereas "if (3 == userChoice)" is just as good as "if (userChoice == 3)" for a comparison, using "if (3 = userChoice)" will always result in an assignment error. It's brilliantly simple . . . but I could never develop the habit of writing those expressions "backwards"! WHPratt (talk) 19:00, 29 December 2009 (UTC)

Yes. While it's somewhat common in some circles to see expressions such as NULL == p, I personally find it hard to read, having a backwards literal reading to normal English logic ("Null is equal to pointer p" instead of "Pointer p is null"). Perhaps the article should have a sentence or two about this programming idiom. — Loadmaster (talk) 19:23, 29 December 2009 (UTC)

The article should not attempt to cover programming style, or it would grow way too large. Also, such matters are disputable; for example, I agree that it is harder to read the "safer" form described by WHPratt above. Frankly, I know of no experienced C programmer who makes the cited mistake, so it's totally unnecessary to contort the natural form of expression. — DAGwyn (talk) 02:38, 13 May 2010 (UTC)

OOP with ANSI-C

"ANSI-C is a full-scale object-oriented language" Object-Oriented Programming With ANSI-C by AT Schreiner - 1993

It would be nice to have a section on OOP techniques. —Preceding unsigned comment added by 128.138.64.222 (talk) 01:03, 19 February 2010 (UTC)

C can be used to create object oriented programs. I've had to do it several times (For the Dreamcast and some embedded systems), but only in cases where no C++ compiler is available. In fact, most early C++ implementations were in the form of a preprocessor to generate straight C code. But it's not what it's for. Nowadays, the circumstances where a C compiler is available but a C++ compiler is not are very few and far between. That was not the case in 1993 (when the article was written), but it is the case now. This article is supposed to be an overview, not a complete be-all and end-all. - Richfife (talk) 01:17, 19 February 2010 (UTC)

Schreiner is simply wrong—so-called "ANSI-C" is not appreciably "object-oriented" in the sense in which that term is currently used by software engineers. In fact, his book illustrates that there is a lot of work needed when using C to simulate an object-oriented language. — DAGwyn (talk) 02:54, 13 May 2010 (UTC)