Talk:C Programming/Language Reference

how many types
Regarding types, how complete do we want these tables to be? There are a few dozen types defined in the standard library, as well as the new boolean and complex types. If no one objects, I'll add _Bool and the _Complexes, but none of the rest. --jcl 19:03, 23 Jan 2005 (UTC)

size in bits
This page is dreadful for teaching C. Beginning programmers can and will make awful assumptions if they are not told which assumptions are reasonable. While a C compiler with a 42-bit char could be standards conforming, such a compiler would be a very sick joke. Instead of leaving newbies to make awful assumptions like "long is always 32 bits", we can say that "long is 32 bits or 64 bits, equal in size to a pointer on non-Windows systems, and always 32 bits on Windows systems". We need not mention anything related to ones-complement or sign-magnitude integers. We need not mention that signed integer wrap-around can cause program termination. (but unsigned won't!) No beginner is going to give a damn about a system that doesn't have a 16-bit short, 32-bit int, and 64-bit long long. Long before even considering the topic of largely theoretical screwball systems, one should discuss the concepts of endianness and natural alignment. This is required for sharing data structures between different systems. AlbertCahalan 07:17, 16 September 2005 (UTC)


 * I agree that this page is dreadful and needs many improvements.
 * However, I don't think telling newbies or anyone else that "long" is "equal in size to a pointer" is ever a good idea.
 * It's not true for Windows -- see Microsoft Developer Network: "Rules for Using Pointers".
 * It's also not true for many non-Windows system -- see vaxocentrism; Intel 8086 mentions various "memory models" with different size pointers -- some of them even have two different size pointers -- which implies that at least one of them was different in size than a long int; "[In Linux] In particular, on the Itanium, a function pointer is 128 bits, a data pointer is 64 bits, a long is 64 bits and an int is 32 bits."-- Peter Chubb; and "wherever pointers are cast to integral types. This practice, which has been condemned for years as inimical to portability" -- "Porting to 64-Bit Intel® Architecture". --DavidCary (talk) 18:34, 8 July 2009 (UTC)

increment and decrement
Regarding (pre|post)(inc|dec)rement, (++ and --), are they really on the same level whether pre or post? K&R1 (1=1st ed.) shows ++ and -- in its operator precedence chart on the same level, but does not state whether they are pre or post. But what makes most sense to me is that post++ would be RIGHT-TO-LEFT associativity and --pre would be LEFT-TO-RIGHT associativity. I wonder if there was a change between K&R1, or if K&R1 is in error, and what effect ANSI-C had. I don't have K&R2 (why buy the same book twice?), so I don't know whether there was a change to the precedence chart. K&R1 also didn't have unary minus, but most compilers nowadays do it anyway--another ANSIism? --Snt (talk) 01:52, 7 July 2009 (UTC)


 * I don't understand. Could you give an example line of code where changing the associativity of predecrement would make any difference? --DavidCary (talk) 18:41, 8 July 2009 (UTC)