Talk:C syntax

From Wikipedia, the free encyclopedia

Contents

[edit] 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)

[edit] 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)

[edit] Evaluation order

The last paragraph 'Evaluation order and Lazy evaluation' is almost completely wrong! Its author should read comp.lang.c FAQ list section 3, especially answer to question 3.5. Constructions like a != NULL && func(a++) do NOT invoke undefined behaviour. The writer is confusing C's short circuit evaluation to lazy evaluation which is a completely different thing. --193.143.83.252 17:36, 26 Mar 2004 (UTC)

Agree completely. That section was completely incorrect. I tried to fix it. Kevin Saff 14:16, 7 Apr 2004 (UTC)
Your version is much better than the original! I just added one sequence point to the list. 193.143.83.252


[edit] vfd

This article was proposed for deletion January 2005. The discussion is archived at Wikipedia:Votes for deletion/C syntax. Joyous 22:46, Jan 22, 2005 (UTC)

[edit] Standard library != C Syntax

The standard library (for which none of the header file names have been provided I might add) has nothing to do with the syntax of C. C can be used with other libraries or none at all; its syntax is independent of them. The translation of command-line arguments is the job of the linker and again has nothing to do with C syntax.

And then I find myself guilty of the same offense, so take what I said with a grain of salt.—Kbolino 05:41, Apr 6, 2005 (UTC)

[edit] 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)

[edit] 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)

[edit] 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)
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 syntax n = 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 syntax int n = 4; is simply a shortcut to int n; n = 4; that combines the two separate operations.—Kbolino 07:07, 6 October 2006 (UTC)
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)
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)

[edit] 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 requires void 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.
The footnote:
9) Thus, int can be replaced by a typedef name defined as int, or the type of argv can be written as char ** argv, and so on.
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 requires void main(void)—a conforming implementation must accept all conforming programs. As for the historical comment, C originally did not have a void keyword or return type (pre-ANSI C).—Kbolino 21:39, 10 December 2006 (UTC)

[edit] 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)

[edit] 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, and static, and added information about const and extern. 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)

[edit] 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)
Retrieved from "http://en.wikipedia.org../../../c/_/s/Talk%7EC_syntax_6cae.html"