Talk:C (programming language)/Archive 10

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 Media copyright questions. --13:49, 8 February 2009 (UTC)

Pointer alignment
Regarding my addition reverted in, 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 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! &mdash;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 &ldquo;Structured programming,&rdquo; structured programming can also be considered a subset of procedural programming, and yet the tag &ldquo;structured&rdquo; is written independently, separated by a comma; according to your logic, the tag would then have to be double-parenthesized and written as &ldquo;Paradigm: imperative (procedural (structured)).&rdquo; Why the inconsistency?  &mdash;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  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)

 for(evar = e_first; evar != e_last; evar++) {...}
 * 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:


 * 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
 * Talk:C (programming language)/Archive 9
 * 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  and  . 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)