Talk:C (programming language)/Archive 1

message: "method" is an unusual word to use for C functions.
"The main method is required in all C programs that are intended to be executed, but it is not necessary for those that are not so intended." sounds like a joke; in fact, AFAIK the difference between a "C program" and a bunch of C code that's not a "program" is precisely the presence of main. Even if I'm wrong and the sentence is perfectly correct, I don't think that sentence will help readers of this article.
Dereferencing a pointer does not change what that pointer refers to, but produces a new value which is distinct from the pointer's value, and which refers to the data at the address stored in the pointer. But that's too long-winded for the article; I think my new phrasing is okay.
The fact that void pointers exist does not "indicate" that they point to an object of unknown type; the fact that they are CALLED 'void pointers' does, but again that's too long to say and it can be finessed with a rephrase.
I fixed a few grammatical errors too.
DanielCristofani 14:10, 17 May 2005 (UTC)
thread_title:  Notes on small changes 

message: A recent editor reverted out an addition of mine, stating:
:All C compilers ignore // comments; the standard requires it. But that is not particularly relevant here anyway
(My addition was (Many modern C compilers can also ignore the // comment delimiter used by C++ code, although doing so may require a command-line qualifier.)
I'm always amused whenever anyone suggests that all somethings do something or no somethings do something; such a statement is usually wrong. And it's certainly wrong in this case: There's no doubt that the class of C compilers also includes the compilers that implemented only the Old Testament and not just the ANSI standard, and those Old Testament compilers most assuredly do not implement that "//" comment delimiter. So the "modern" part of my comment was absolutely correct. And the portion about requiring a command-line qualifier was also correct; reasonably-recent and definitely ANSI-compliant versions of the Sun Workshop compilers most-assuredly DO require such a qualifier, although GCC doesn't.
: This depends on what you mean by "C compiler". I usually take it as an implementation of the C standard, and for the sake of clarity, this seems to make the most sense in an encyclopedic article. In which case the statement is provably correct. And if Sun Workshop does not accept it by default, then it's clearly not standards compliant. --Mellum 16:20, 18 May 2005 (UTC)
replies: text: However, the point of that paragraph was not to give a complete explanation of comment syntax, but rather to give a brief overview of C's syntax in general; therefore, I considered these obscure details too distracting. But I don't feel very strongly about that. BTW, "//" is not from C++, but from BCPL. --Mellum 16:20, 18 May 2005 (UTC)
thread_title:  "ALL" as a dangerous term 

message: I disagree with the list of features C does not have - in that C supports Metaprogramming.
In the article on Metaprogramming, listed as an example of Metaprogramming, is the 'Quine' - "a special kind of metaprogram that has its own source as its output". There are plenty of Quines in the C language. Here's an example:
char*f="char*f=%c%s%c;main(){printf(f,34,f,34,10);}%c";main(){printf(f,34,f,34,10);}
Therefore, by at least this one example, C supports Metaprogramming. Many more are likely to be found as entries for the IOCCC.
Ben-Arba 07:08, Jun 18, 2005 (UTC)
:The concept of "metaprogramming" is rather difficult to define, as Talk: Metaprogramming shows. Under some loose definitions, even compilation is metaprogramming. I'd say that a C program, in general, cannot reason about or modify its own structure, except maybe with macros, and there only in a primitive sense. Deco 01:03, 19 Jun 2005 (UTC)
replies: text: Okay, that's fine, I'll remove it. Deco 07:46, 19 Jun 2005 (UTC)
thread_title: Feature list - Metaprogramming

message: Since the watchers of this page evidently have interest in C, I thought some of you might be interested in commenting on the deletion vote Wikipedia:Votes for deletion/C Programming Mistakes for the article C Programming Mistakes. Deco 21:43, 14 July 2005 (UTC)
thread_title: VfD: C Programming Mistakes

message: I removed this comment from the Problems with C section:
:Rather than placing these checks in the compiler, additional tools, such as Lint, were used.
This is true for some such checks, but others are made undecidable by the lack of limitations on the language. This comment misleadingly suggests that all problems with C can be overcome by a sufficiently intelligent tertiary static checking tool, which is false, and that Lint is this tool, which is even more false. Deco 01:28, 15 July 2005 (UTC)
replies: text: I think the point of the original text is that some semantic checks were intentionally left out of the compiler itself, and were intended to be implemented in tools such as lint (I don't personally know with certainty whether or not that is true, but I've heard the same statement elsewhere). I don't think it is suggesting that "all problems with C" can be resolved via the use of a static checker (which is obviously false). Neilc 01:34, 15 July 2005 (UTC)
replies: text: I agree.  The reference to Lint should stay, but it should be shown to be only a partial solution.  Something like "Additional tools, such as Lint, were used to attempt to do the checks left out of the compiler"?  --A D Monroe III 01:45, 15 July 2005 (UTC)
replies: text: This is already discussed at sufficient length in the final subsection. I don't feel like it's necessary to reiterate it the section introduction. Deco 02:13, 15 July 2005 (UTC)
thread_title:  Removed lint comment 

message: For the unnamed user editing the intermediate language section, why not go ahead and try rewording the first sentence or two in the section as well.  Perhaps break the sentences up a little more and rewording phrases like "which then outputs finished object or machine code". Laundrypowder 20:44, 16 August 2005 (UTC)
thread_title:  Intermediate language wording 

message: The reasoning behind current Visual Studio C99 support might as well be added.  As seen on this transcripts http://msdn.microsoft.com/chats/transcripts/vstudio/vstudio_022703.aspx:
Q: Follow-up on the C99 "varargs" question, what, if anything, from C99 will we see in the future from VC
A: In general, we have seen little demand for many C99 features. Some features have more demand than others, and we will consider them in future releases provided they are compatible with C++. It is more likely we'll entertain C99 features if they are picked up in the next version of the C++ standard.
The phrase on their compilers could be worded a little more informatively as they consider new Visual C++ versions really only a c++ compiler.
Laundrypowder 14:37, 25 August 2005 (UTC)
thread_title:  C99 features 

message: A lot of security holes result in the wrong usage of printf to output strings. Why the hell would someone believe 
 printf (some_string); 
 to be useful code, if not for all the misleading example code, which demonstrates that printf outputs strings.
An example should use functions in the way that they are meant to be used. Examples should not just happen to work for that special case.
Therefore I argue that 
 printf ("hello, world\n"); 
 is to be replaced by 
 puts ("hello, world"); 
 or 
 printf ("%s", "hello, world\n"); 
 -- Hokanomono 15:40, 21 September 2005 (UTC)
replies: text: printf("some string") is perfectly fine C code. It's idiomatic and has been in C examples at least since the Old Testament. I have no idea how this could cause a serious security problem (mismatch between format string and arguments might cause a problem. sprintf() might cause a problem. scanf() might cause a  problem. But plain printf()?). About the only reason that puts() might be preferable is efficiency, which only plays a role in very exotic circumstances. The "Hello, world" example with printf() is straight from K&R2, the standard C introduction. --Stephan Schulz 16:03, 21 September 2005 (UTC)
replies: text: I agree with Hokanomono here. Instances of printf("I ignorantly use %s here.") and printf(string_from_network) are real problems. Examples stick to a beginner's mind and they try to expand from them. I suggest puts("hello, world") if we don't go into explaining format strings here. ANSI C and POSIX.1 have puts so it's standard. --TuukkaH 17:09, 21 September 2005 (UTC)
replies: text: But the purpose of Wikipedia is not to teach bullet-proof coding practices, but to explain what C is. I claim that printf() is a much more useful feature than puts(), and, in existing code, much more used even with constant, zero-argument format strings. So it illustrates the existing language better.--Stephan Schulz 19:20, 21 September 2005 (UTC)
replies: text: Further, the purpose of Wikipedia is not to teach useful features such as printf :-) puts illustrates the language well, although perhaps not the prevailing usage. We have to agree that we're talking about an example which tries to illustrate what simple C looks like. C is not the tool of choice for string processing. If printf is kept, I hope the shortcomings are pointed out at least. --TuukkaH 21:15, 21 September 2005 (UTC)
replies: text: "printf" typifies C, "puts" does not.  As noted, the example is from K&R!  If K&R changes, we must match it, but not before.  --A D Monroe III 01:38, 22 September 2005 (UTC)
replies: text: Only the first example is from K&R, I agree that it should be presented in original form. However, there is a modern example following K&R's that should be the subject to our discussion. – Hokanomono 06:55, 22 September 2005 (UTC)
replies: text: Which example? The second Hello-World closely follows K&R2 (except fot the added return). I think both should agree. I have no strong opinion on further examples (which probably means I'm a traditionalist and all my arguments are a rationalization ;-)--Stephan Schulz 08:34, 22 September 2005 (UTC)

text: This is all much ado about nothing.  True, printf("I ignorantly use %s here.") and printf(string_from_network) are real problems.  But this is no reason to abandon printf entirely!  Similarly, i=i++ is a problem, but this does not mean that we abandon the extremely useful ++ operator.  Similarly, sqrt(-1) is a problem, but this does not mean that we ditto.  You solve these problems by teaching people about them so that they can learn to use the language correctly and appropriately, not by castrating the language so that it's somehow "safe".  This is, after, all, C we're talking about here, not Pascal! Steve Summit (talk) 01:00, 11 December 2005 (UTC)
thread_title:  Hello, world 

message: Someone has been adding a number of "Notes" to the article. While they seem well-intended, they are somewhat unclear and at least partially incorrect. I also think they don't belong into an encyclopedia as such - any useful information should go into the main text. I tend towards just removing most of them - any opinions? Here are mine:
* malloc() and calloc(): True but irrelevant. It is easy to avoid uninitialized memory, but it still is a frequent error. And there are good reasons to prefer malloc() in many cases.
* Modern garbage collectors do not add "tremendous overhead" to either runtime or (non-trivial) program code - indeed, they are often faster than explicit memory handling (Note: I'm a fan of explicit memory handling...;-). 
*  Pointer casting: This is plain wrong. void* pointers can be cast implicitely. This is not C++.
* Opaque structures: True, but it still is harder (or at least less convenient) than in OO languages with private members.
--Stephan Schulz 21:34, 27 September 2005 (UTC)
replies: text: I agree that they should be removed.  Even if correct, they probably should have been in parenthesis rather than as a note. wrp103 (Bill Pringle)  - Talk 14:23, 28 September 2005 (UTC)

text: I also agree to these corrections. I'm sorry that they slipped by me. I do recall that I was the one who first asserted that opaque structures are difficult to implement in C. (perhaps my original wording was too strong) Deco 02:35, 19 November 2005 (UTC)
thread_title:  Notes (by 68.199.16.197) 

message: I just made several significant changes to the Types section.  Since the old text had been there for a while (and presumably accepted), I'd probably better explain my changes here, in case anyone has questions:
* Saying that a pointer is a "complex type" at compile time, or is nothing but a raw memory address at run time, are both misleading.  Some C systems implement "smart pointers" which carry around e.g.  bounds-checking information; these can be made completely compatible with the language definition.
* The statement "Unlike many other languages, C typically represents arrays just as it does pointers" is simply false.  Arrays are not pointers and are not "represented as" pointers; the "memory address" and "associated type" of an array are perfectly analogous to the address and type of a single, ordinary variable.
* I deleted "reveal confidential data" from the list of potential consequences of array bounds violations, since if this is a possibility, it means you have serious problems at the OS level, far beyond any limitations of the C language.
* C does not formally have multidimensional arrays; I thought this was discussed to death under "confusion about arrays" above.
* No one "treats a double-precision value as an integer" in "low-level systems programming".  Programmers in all sorts of applications often have to convert back and forth between integers and floating-point quantities; this is straightforward (and doesn't even require a cast).  What's tricky (and more "low-level") is to interpret the bits of a value as if they had some other type, but without converting them.  You can't use a simple cast for that!  (Though you might use a cast as part of the more complicated pointer expression you were using as part of the low-level bit inspection).
Steve Summit (talk) 02:32, 11 December 2005 (UTC)
thread_title:  notes on rewrite of '''Types''' section 

message: As far as I know, functions such as calloc, realloc also count. So, I changed the line 
blocks of memory of any desired size can be requested at run-time using the library function malloc() to blocks of memory of any desired size can be requested at run-time using library functions such as malloc()
: No, but it is the standard memory allocator (iirc). Dysprosia 11:09, 29 December 2005 (UTC)
thread_title:  Is malloc the only dynamic memory allocator?