Talk:C syntax/Archive 1
This is an archive of past discussions about C syntax. 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 1 | Archive 2 |
Comments on changes to the Functions > Description section
In the third paragraph, "A definition is a special type of declaration. A variable definition sets aside storage and possibly initializes it, a function definition provides its body."
I wonder if "A variable definition" should be changed to "A variable declaration".—The preceding unsigned comment was added by BbEcPeter (talk • contribs) 11:07, 17 August 2005.
- It should not be changed. Variable definitions are not the same as variable declarations. Definitions set aside storage while declarations do not. Denis Kasak 13:36, 23 September 2005 (UTC)
- I disagree with that statement. On the contrary, I'm quite sure that declarations (e.g.,
int n;
) set aside the storage (albeit containing memory noise), and the definitions (e.g.,n = 4;
) asign values to the allocated storage.—Kbolino 06:27, 5 October 2006 (UTC)
- I disagree with that statement. On the contrary, I'm quite sure that declarations (e.g.,
- Common usage is closer to what Dkasak described. Technically according to the C standard they are all declarations, and whether a declaration is also a definition (specifies storage, or provides a function body) or not is a secondary issue. For objects, whether or not storage is allocated is independent of whether an initializer is specified. — DAGwyn 20:29, 5 October 2006 (UTC)
- I'm not trying to be rude, but what you said doesn't make any sense—at least not in terms of my comment. The two are, in fact, quite different operations. At the very least, the operation corresponding to the syntax
int n;
will create the symbol 'n', assign it a location in memory, reserve the necessary space in memory at that location, and declare its type to be integer. The operation corresponding to the syntaxn = 4;
will simply write the integer value '4' to the location assigned to the variable 'n'. There is a very clear distinction there to me. The syntaxint n = 4;
is simply a shortcut toint n; n = 4;
that combines the two separate operations.—Kbolino 07:07, 6 October 2006 (UTC)
- I'm not trying to be rude, but what you said doesn't make any sense—at least not in terms of my comment. The two are, in fact, quite different operations. At the very least, the operation corresponding to the syntax
- But there are declarations that don't set aside storage etc.:
extern int n; void foo(int);
Also, an initializer in a declaration (=
value) isn't quite the same as a run-time assignment, on several counts. Certainly, run-time assignment itself isn't normally considered a "definition" of anything. The cited text from the third paragraph of the article seems accurate enough. — DAGwyn 19:54, 6 October 2006 (UTC)
- But there are declarations that don't set aside storage etc.:
- The term variable definition does not exist in K&R C; the only things that can be defined are functions—the definition of which is a type of declaration—and macros. Accordingly, variables are declared, in statements known as declarations (K&R C, 210). What I called definition is actually assignment—but that doesn't change the fact that what the article calls definition is actually declaration.—Kbolino 03:18, 7 October 2006 (UTC)
Comments on changes to array section
I appreciate someone checking me for my errors; humility is a good thing. However: I have a few comments on the changes that were made. The section "Accessing elements" contains the following wording prefacing a table:
It is also possible to use pointer arithmetic to specify the reference value for each of the array elements. The following table illustrates both methods for the existing array:
The header is also labeled "Pointer." This would imply that the statement therein listed would be of the reference type. However, the derefence operator was added. Perhaps this should not be in place, or the wording modified to reflect this change.
I have found that neither my nor the given conclusion about the initial address of a pointer is correct. Pointers, like primitive variables, are ASSIGNED no value; they assume the value of the space of memory over which they were created. There is therefore an address associated with them, it is just useless.
Function names should never be shown with incorrect capitalisation. The identifiers Printf and printf completely different. It is therefore necessary to never begin a sentence with a function name, in order to alleviate two forms of confusion.
Additionally, an assignment from void *
to any other reference type does NOT require a cast. It is a widening implicit cast and should not produce any warnings.—Kbolino 00:16, Apr 15, 2005 (UTC)
- Except that means
int i = 4; void *p = &i; char *s = p;
- is perfectly valid and warningless. Is that right? Most C compilers I know will warn about this. 202.180.83.6 22:52, 16 January 2006 (UTC)
- What's a year between Wikipedians? Anyhow, as an update to this, and not necessarily in support of my statement, but simply to clarify the issue, I created a C program using the given code in a simple wrapper:
int main() { int i = 4; void *p = &i; char *s = p; return 0; }
- In gcc 3.4.6 and Borland C++ 5.6.4, with all warnings enabled, the only warnings produced were about the variable 's' never being used:
$ gcc -Wall warntest.c ./warntest.c: In function `main': ./warntest.c:4: warning: unused variable `s'
> bcc32 -w warntest.c Borland C++ 5.6.4 for Win32 Copyright (c) 1993, 2002 Borland warntest.c: Warning W8004 warntest.c 7: 's' is assigned a value that is never used in function main
- I do not have a copy of Visual C++ (or any other compiler) to test, but I imagine they would similarly only warn about 's'.—Kbolino 06:16, 5 October 2006 (UTC)
it might be interesting to include here that as a consiquence of the way that array subscripting works we can have things like 3["foobar]
or 15[a]
. It might be better in obfuscated code though, so I'll just mention it here. --Michael Lynn 01:00, 2 November 2006 (UTC)
Wikibooks vs. Wikipedia
Is it considered OK for a large degree of duplication to be present between Wikipedia and Wikibooks articles? All the content of this page would inevitably be in Wikibooks:Programming:C. So should the information be duplicated here? There could be a similar issues with many other articles here. Probably there is some precedent to such issues? -- Paddu 21:14, 16 Mar 2004 (UTC)
- Wikipedia should provide summary information, but should not provide extensive examples, self-test problems, or anything like that. The two projects are for different purposes, not different information. Fresheneesz 09:38, 21 November 2006 (UTC)
Bitwise operators
Where are they?Uranther 01:54, 12 February 2006 (UTC)
- While this article does go beyond the scope of speaking of C-specific syntax in some places, bitwise operators are not unique to C and are used in nearly every modern language. For stuffs like that, Wikibooks:Programming:C would be the place to look. Utopianheaven 21:19, 20 July 2006 (UTC)
- I disagree. This article is not on syntax unique to C, its on the entirety of c syntax. Exclusion of bitwise operators isn't acceptable. Fresheneesz 09:46, 21 November 2006 (UTC)
Comments on void main(void) and other tidbits
After examining the article I found that it is not in a particularly good state, the primary reason being that it's inconsistent in its use of coding style, and what is even more worrying, declarations of main(). According to the C standard, the only two valid declarations of main are int main(void)
and int main(int argc, char **argv)
. The article gets these wrong and it needs correction. I'll attempt correcting this myself, and if anyone has further suggestions, please reply here. Denis Kasak 13:51, 23 September 2005 (UTC)
- I don't think that's important. Remember that there are currently many C standards with different versions of
main()
, among other things. In my business with an embedded processor, the compiler I'm using requiresvoid main(void)
. This article isn't just about current standards anyway, but also includes the primitive origins of C. --A D Monroe III 20:37, 6 October 2006 (UTC)
- Excuse me, but there is only *one* current C standard. If i'm not wrong, void main(void) has *never* been part of that standard. Just because a compiler does it, doesn't mean its standard. If this article includes older versions or the origins of C, it should have a history section. Fresheneesz 09:48, 21 November 2006 (UTC)
- From ISO/IEC 9899:1999 (C99), section 5.1.2.2.1 "Program startup":
- 1. The function called at program startup is named main. The implementation declares no prototype for this function. It shall be defined with a return type of int and with no parameters:
int main(void) { /* ... */ }
- or with two parameters (referred to here as argc and argv, though any names may be used, as they are local to the function in which they are declared):
int main(int argc, char *argv[]) { /* ... */ }
- or equivalent;9) or in some other implementation-defined manner.
- 1. The function called at program startup is named main. The implementation declares no prototype for this function. It shall be defined with a return type of int and with no parameters:
- The footnote:
- 9) Thus,
int
can be replaced by a typedef name defined asint
, or the type ofargv
can be written aschar ** argv
, and so on.
- 9) Thus,
- Note the clause "or in some other implementation-defined manner." That is, the use of
void main(void)
is perfectly allowable; but A. D. Monroe's compiler is not a conforming implementation because it requiresvoid main(void)
—a conforming implementation must accept all conforming programs. As for the historical comment, C originally did not have avoid
keyword or return type (pre-ANSI C).—Kbolino 21:39, 10 December 2006 (UTC)
Keywords
Since this is an article about the C language syntax, shouldn't it also include a list of the reserved keywords (and perhaps the reserved identifiers)? — Loadmaster 23:17, 1 March 2007 (UTC)
- I went ahead and added a "Reserved keywords" table in the "Miscellaneous" section. — Loadmaster 23:35, 6 March 2007 (UTC)
Neccessary additions
This page needs a LOT of additions that it doesn't cover. I just added stuff on the const modifier, register, auto, and static. The page doesn't even mention structures or unions, doesn't mention the extern keyword. It doesn't mention function pointers. I'd have to say that this page requires extensive cleanup, even for the information it does have. Fresheneesz 09:45, 21 November 2006 (UTC)
- I cleaned up your notes on
register
,auto
, andstatic
, and added information aboutconst
andextern
. I had to read the related appendices in K&R C several times before I understood them, so it's no wonder discussion didn't appear in the article.—Kbolino 21:45, 10 December 2006 (UTC)
- Added structs and unions too.—Kbolino 03:48, 26 December 2006 (UTC)
It's also missing some C99 additions: imaginary (_Imaginary) floating-point types, boolean types (_Bool and <stdbool.h>), enumerated types (enum), etc. — Loadmaster 23:53, 6 March 2007 (UTC)
- Enums predate C99. They may have been in K&R C, but I know they were in ANSI C. I'll add a note about them, though. —Kbolino 02:17, 7 March 2007 (UTC)
- ANSI C is C89, i.e., the ANSI 1989 standard, which became ISO 9899-1989. And yes, C89 had
enum
. — Loadmaster 23:17, 18 October 2007 (UTC)
- ANSI C is C89, i.e., the ANSI 1989 standard, which became ISO 9899-1989. And yes, C89 had
Image source problem with Image:CCommandLineArgv.png
Thanks for uploading Image:CCommandLineArgv.png. I noticed that the file's description page currently doesn't specify who created the content, so the copyright status is unclear. If you did not create this file yourself, you will need to specify the owner of the copyright. If you obtained it from a website, then a link to the website from which it was taken, together with a restatement of that website's terms of use of its content, is usually sufficient information. However, if the copyright holder is different from the website's publisher, their copyright should also be acknowledged.
As well as adding the source, please add a proper copyright licensing tag if the file doesn't have one already. If you created/took the picture, audio, or video then the {{GFDL-self}} tag can be used to release it under the GFDL. If you believe the media meets the criteria at Wikipedia:Non-free content, use a tag such as {{non-free fair use in|article name}} or one of the other tags listed at Wikipedia:Image copyright tags#Fair use. See Wikipedia:Image copyright tags for the full list of copyright tags that you can use.
If you have uploaded other files, consider checking that you have specified their source and tagged them, too. You can find a list of files you have uploaded by following this link. Unsourced and untagged images may be deleted one week after they have been tagged, as described on criteria for speedy deletion. If the image is copyrighted under a non-free license (per Wikipedia:Fair use) then the image will be deleted 48 hours after 11:55, 25 November 2007 (UTC). If you have any questions please ask them at the Media copyright questions page. Thank you. Papa November (talk) 11:55, 25 November 2007 (UTC)
Coding style
Not to start a flame war here, but I suggest that for consistency we use the brace style used in the ISO/IEC 9899 C99 standard. This style has the braces aligned underneath their controlling keyword. — Loadmaster (talk) 17:16, 8 February 2008 (UTC)
Is this the right article for defining identifier names?
E.g., that identifiers can start with a letter (a-z, A-Z), or underscore (_) and may followed by zero or more letters (a-z, A-Z), digits (0-9), and underscores (_). Your identifier may not be a reserved keyword. The following are valid identifiers:
- i
- Pizza
- _pizza
- pizza_box37
- Pizza1Box
- PIZZA
These are illegal identifiers
- pizza box - An identifier can't contain a space.
- 1pizza - An identifier may not start with a digit.
- goto - An identifier may not be a reserved keyword.
There are no restrictions on how long an identifier may be.
Identifiers are case sensitive; Pizza, pizza, and PIZZA are all separate identifiers.
While the standard allows it, some systems reserve, and thus do not allow, identifiers that start with underscore followed by an upper case letter or that start with two underscores. Thus care should be used with _PIZZA or __pizza as the code may not be portable.
The reason I visited this article is I inherited a Microsoft Visual C++ 6.0 project and saw this
pizza$box = 123;
After wondering what on Earth the $ operator is I discovered that $ is allowed in identifiers and is handled just like _. I have no idea if $ is included in the C++ standard though and that's why I came to the Wikipedia to see if there already was a section about this. Code such as _ = pizza + $;
is accepted by the compiler and it works... One comment[1] says that $ should be reserved for mechanically generated names. Marc Kupper (talk) (contribs) 08:15, 1 December 2007 (UTC)
- Absolutely. A useful reference here is ISO/IEC 9899:1999 (C99); start at section 6.4.2. The answer is that implementations may allow other characters to appear in identifiers, but are not required to. An interesting aspect of C99 - I don't think it's used all that much - is that Unicode escapes are required to be allowed in C99 programs. Thus:
int \u0024 = 9;
is a valid C99 statement. EdC 23:02, 1 December 2007 (UTC)
- Assuming, of course, that
$
is a valid identifier in your compiler. Another example would be:
- Assuming, of course, that
int ol\u00E9 = 9; // olé
- C99 constrains Unicode characters within identifiers to be anything outside the regular ASCII subset it accepts. — Loadmaster (talk) 21:08, 14 October 2009 (UTC)
Memory Requirement
In this page specifications regarding memory allocation of integers is tabulated. But it is compiler and platform dependent. Memory allocation of int is listed as 16 bits. But today gcc compilers along with 32bit (onwards) microprocessor platform allocate 32 bits for an integer. So it should be changed. At least, it should be mentioned that it is compiler dependent.AshishDandekar7 (talk) 07:42, 28 July 2011 (UTC)
- As stated in the sentence preceding the table, The following table provides a complete list of the standard integer types and their minimum allowed widths (including any sign bit). Which means that 16 bits is the minimum width required for the
int
datatype in ISO-compliant C compilers. — Loadmaster (talk) 19:28, 28 July 2011 (UTC)
Comments on changes to primitive data types
Kbolino, I don't agree with your changes. The technical language you use is not that of C; before your changes the wording was precisely that used in the C standard. e.g. the standard refers to floating types. I don't think those paragraphs have improved at all; I chose my wording carefully, and to me at least they seem much worse now than before. In fact, a lot of what you wrote is now simply incorrect. Akihabara 06:58, 19 Apr 2005 (UTC)
KBolino, since you've not replied, I intend to revert your changes to this section in the next 24 hours. Akihabara 07:09, 20 Apr 2005 (UTC)
- Simply because I'm viewing this page now, I'll add my comments (even though they are a year and a few months late). The first is that my "language" came from Java, and as I now possess a copy of K&R C 2/e, I can more accurately represent the "technical language" of the "C standard". However, it is worth noting that while C may have pioneered the ideas, the use of more modern language, insofaras at least comparing C terminology to more recent terminology, is certainly not without merit. Factual inaccuracies are a different matter, though.
- I would also like to note, should anyone actually ever read this or care, that comments directed towards a specific person should probably be posted to that person's user page, and if not, well more than a day should be given (though a year and a few months is a little unreasonable)—Kbolino 06:23, 5 October 2006 (UTC)
The table shown has an Unsigned data type. Shouldn't it be 'Unsigned int' data type? — Preceding unsigned comment added by 221.120.220.13 (talk) 12:54, 10 October 2011 (UTC)
What about else if.
I am not sure if this is really necessary but it seems like there ought to be a comment on the else if
selection statement. I suppose the if
section covers this but else if
is decidedly common and is not intuitively obvious from the current section.
I was thinking:
if (<expression>)
<statement1>
else
<statement2>
In the if
statement, if the <expression> in parentheses is nonzero (true), control passes to <statement1>. If the else
clause is present and the <expression> is zero (false), control will pass to <statement2>. The "else <statement2> part is optional, and if absent, a false <expression> will simply result in skipping over the <statement1>. An else
always matches the nearest previous unmatched if
; braces may be used to override this when necessary, or for clarity. Multiple if
statements can be used in conjunction by including an immediate if
after an else
. This format allows for the organized arrangement of numerous often, but not inherently, related if
statements.
if (<expression1>)
<statement1>
else if (<expression2>)
<statement2>
else
<statement3>
— Preceding unsigned comment added by Hikinandbikin (talk • contribs)
- Count me on the "unnecessary" side. The "if statement" section already describes all that is necessary to understand that any statement (not just another "if") can be placed immediately following an "else" while dropping the optional newline, or indentation, or curly brace. So "else if", while often seen, is not distinct syntax any more than "else switch" or "else for"; it is just one of many ways to apply the already described syntax of C. My $0.25. --Ds13 (talk) 00:23, 1 November 2011 (UTC)
Template C-lang bugs
A recent edit (diff) introduced a new template, {{C-lang}}. I noticed that the edit was broken because it was performed with an automated search and replace that did not account for the fact that some <code>...</code>
wikitext was originally incorrect, with improper closing of some tags (but which apparently rendered correctly in the article). I did another massive edit to fix that, but an IP user has just performed some edits trying to fix another problem. I don't have time to fix this now, so I'm just going to document what I have noticed:
- pipe bug:
{{C-lang||}}
→ - entity bug:
{{C-lang|<stdlib.h>}}
→<stdlib.h>
There is only one more pipe bug to workaround, but lots of character entities. I'll probably get back and do something soon, but the issue needs to be recorded anyway (is the template worthwhile if it has these problems and if they can't be fixed except with ugly workarounds?). I will let the template author know about this. Johnuniq (talk) 00:53, 14 August 2011 (UTC)
- For the record, I noticed another bug: using "nowiki" in the template parameter fails:
{{C-lang|<nowiki>''</nowiki>}}
→''
- Fixing the issues was easier than I thought, and I believe it's now all done. Johnuniq (talk) 07:25, 14 August 2011 (UTC)
- The template has a category called [[Category:Articles with example C code]]. It intends that whenever a page on Wikipedia uses this template, this page is automatically entered to the given category. I noticed that there needs another fix, as the pages are not added to this category. If a fix is not possible, I propose to remove this category, as it is useless in this case. Sae1962 (talk) 14:10, 14 August 2011 (UTC)
- There's another example in the paragraph preceding Enumerated Types. When discussing the octal format, the zero does not show and it uses the C-lang syntax. I don't know enough to fix it. -shri 31 October 2011 —Preceding undated comment added 23:38, 31 October 2011 (UTC).
- I removed the template instances from the “Integer types” section, that’s one way to fix the bug :P. In general I’m not really happy with the formatting this template produces when used amongst English paragraphs, and it seems the formatting is its main purpose. Vadmium (talk, contribs) 06:18, 1 November 2011 (UTC).
Undefined behavior
I don't see how this is undefined behavior at all in STDC. It should evaluate to 2 every time, because b++ increments b after the current expression. -- KneeLess 02:04, 21 Feb 2005 (UTC)
- Err, what is? 202.180.83.6 22:47, 16 January 2006 (UTC)
- Nope, assuming you mean b++ + b++, that's definitely UB. — DAGwyn 23:59, 29 September 2006 (UTC)
- Assuming we're talking about the
a + b++ + b++;
example, then it is most definately undefined, here is why. It is true that the postincrement operator will garantee that after the expression it will be incremented, but it is not defined at exactly which point it will do the increment...put in other words, you are garanteed that b will get the first post increment after the first instance of b is used or after it adds the two. All you are garanteed is that b will be updated before the next sequence point...for a better (more complete) explanation I refer you to the venerable comp.lang.c faq questions 3.2, 3.8, and 3.11 --Michael Lynn 00:46, 2 November 2006 (UTC)
I suggest verifiability for that section and have tagged it as such. I will research more, but I offer a potential reference here: https://www.securecoding.cert.org/confluence/display/seccode/CC.+Undefined+Behavior#CC.UndefinedBehavior-ub1 --Ds13 (talk) 22:02, 16 November 2011 (UTC)
- This doc, on page 491 (J 2) might be a treasure chest of C's undefined behaviours. http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf --Ds13 (talk) 22:05, 16 November 2011 (UTC)
Which C?
We could mean a few things by C, the primary choices being K&R C, ANSI C circa 1989, C99. As written, the post is wishy-washy about what C is, even though any current user is using a compiler that conforms with everything we've said about C99. I believe that the post would be clearer if it were written from the perspective of the current standard, and notes given where C89 or K&R differ. This is in contrast to what we have now, which gives two or three equally-weighted options (in random order) for everything that has ever changed in the language. B k (talk) 13:46, 14 October 2009 (UTC)
- A reasonable position to take would be to assume we're talking about the latest international ISO/IEC standard C (which is currently C99). Features of other versions of the language (K&R, C89, C90, MSC, gcc, etc.) should be explicitly indicated as such. And be aware that it's not true that all current compilers conform 100% to C99 (e.g., MS Visual C). — Loadmaster (talk) 21:02, 14 October 2009 (UTC)
- This needs to be fixed, in my opinion. If one wishes this to be about C99 then it should say so. A discussion without framing just chases it's tail. 108.67.200.56 (talk) 13:31, 10 September 2012 (UTC)
Bit fields
Is the empty entry thing a C99- or C11- ism? Naively trying this code out on gcc:
struct foo {
int a : 1;
int b : 2;
: 5;
};
I see the following error:
test.c:4:5: error: expected specifier-qualifier-list before ‘:’ token
Am I doing something wrong here? 216.228.112.21 (talk) —Preceding undated comment added 17:49, 16 November 2012 (UTC)
- Try “int: 5”. You still need to give it the data type, even if it is anonymous. No idea what version of the standard (or from before standardisation) it came from though.
- Hmm, a closer look at the article and I see it also uses the syntax without any data type. My experience and a quick google suggests this is an error, though I don’t have a C standard to look at. I might fix it anyway. Vadmium (talk, contribs) 07:35, 17 November 2012 (UTC).
Switch in other control structures !?
..though unusual, to insert the switch labels into the sub-blocks of other control structures..
Does anyone know of any examples of this (disclaimer, I haven't looked at the pages for Putty or other things listed, so they might be there..) Or does this pretty much fall into the "only in obfuscated code contests" category (excepting things like co-routines - which some might say are obfuscated code..) Jimw338 (talk) 14:56, 3 September 2013 (UTC)
- Take a look at Duff's device, probably the most famous example of this. — Loadmaster (talk) 17:57, 3 September 2013 (UTC)
"An empirical study of goto in C code"
"An empirical study of goto in C code" (2015 paper) https://peerj.com/preprints/826v1.pdf and https://peerj.com/preprints/826v1/
"We conclude that developers limit themselves to using goto appropriately in most cases, thus suggesting that goto does not appear to be harmful in practice."
• Sbmeirow • Talk • 22:01, 16 February 2015 (UTC)
Iteration Statements section
Please expand the "Iteration Statements" to include discussion and examples of "continue" and "break" use within a "loop". • Sbmeirow • Talk • 19:29, 29 September 2015 (UTC)