Talk:C (programming language)

"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)

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)

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:

1. stack variable alignment on a boundary of multiple of 8,
2. the __packed qualifier that would make the compiler access adjacent words and combine them into a result,
3. 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)

Array-pointer interchangeability

Should the main article mention that the types of the following 3 expressions are different?

  &arr[0]
  arr
  &arr

As a consequence of the recursive application of the derived type/element type relation described in 6.2.5 Types, par. 20 of WG14 N1124, &arr[1] and &arr + 1 will point to different areas if arr has more than 1 element. --ilgiz (talk) 17:04, 2 April 2009 (UTC)

• I don't think the article should try to explore such details; it's not a programming tutorial. — DAGwyn (talk) 18:12, 6 May 2009 (UTC)

About this phrase->

"Despite this apparent equivalence between array and pointer variables, there is still a distinction to be made between them. Even though the name of an array is, in most expression contexts, converted into a pointer (to its first element), this pointer does not itself occupy any storage, unlike a pointer variable. Consequently, what an array "points to" cannot be changed," [...]"

IMHO, I think that text in bold is not a good indication of distinction between array and pointer, because the same restriction applies to const pointers (these also we can`t change what they points to), as in:

int *const MyPointer;

So in my opinion, text in bold should be deleted from article. Also, can it be that array variable REALLY is just read-only pointer ? (as in my given example). —Preceding unsigned comment added by 84.32.222.96 (talk) 20:38, 12 November 2009 (UTC)

• No storage for the array address means compile time calculation of its offsets. The const modifier of the pointer may be circumvented at run time by casting. Modifying array offsets at run time would require interfering with the generated code and temporary storage. --ilgiz (talk) 21:33, 12 November 2009 (UTC)
  • Thanks, for explanation about pointer const modifier circumvention. Now i am totally confused. Whats the point of having const modifier if we can bypass it by just casting ? Huh. IMHO, this may be design flaw in C. This may mean that:

1. C don`t needs const modifier for pointers at all. OR

2. C should be changed such that const modifier may not be bypassed by simply casting const pointer to non-const pointer before address assigment.

It`s a pitty that such flaw exists. —Preceding unsigned comment added by 84.32.222.96 (talk) 09:37, 13 November 2009 (UTC)

• Number (2) is already in place. I believe a warning may be emitted by a C compiler when const-ness is cast away. The point in allowing a bypass is to work around the older code unaware of const modifiers when it interleaves with the new code. The proper fix would involve massive changes to the older code. --ilgiz (talk) 16:48, 13 November 2009 (UTC)

The const keyword is meant to be part of the contract between the function provider and the client. As such, it is designed to inform the client that there is a promise that a variable or parameter will not be modified by the function. However, since the variable may actually be provided by the function writer (especially if it is an opaque structure), it is reasonable to allow it to modify the variable as part of its internal operation. Thus the possibility of "casting const-ness away" provided by the language. C was designed with the principle that the programmer knows what he is doing, and therefore it should provide features to allow him to do useful things instead of hindering him. By the same token, the programmer must explicitly override the default behavior in order to do this. — Loadmaster (talk) 00:07, 14 November 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:

• Talk:C (programming language)/Archive 8#Source language = C formatting
• Talk:C (programming language)/Archive 9#Howcome no syntax highlighting?

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)

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)

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)

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)

---

---

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)

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)

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)

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

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)

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)

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 dynamic language is better for websites... what about C/C++/Java ?

2.) High usage websites use C/C++/Java in mission 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 ?