Jump to content

Talk:C (programming language)/Archive 14

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 10←Archive 12Archive 13Archive 14Archive 15Archive 16Archive 17

Hello world, revisited

The standards-compliant "hello, world" example is only compliant for C99 and higher. I think it needs to be clarified that it isn't compliant with C89. — Preceding unsigned comment added by Tommyinla (talk • contribs) 06:53, 17 February 2013 (UTC)

What's not C89 compliant about it? The only thing I can see is that implicit "return 0" at the end of main() is more clearly and explicitly defined in C99, although it *is* defined in C89 (2.1.2.2 Hosted environment (...) "Program termination" (...) A return from the initial call to the main function is equivalent to calling the exit function with the value returned by the main function as its argument. If the main function executes a return that specifies no value, the termination status returned to the host environment is undefined. and 3.6.6.4 The return statement (...) Reaching the } that terminates a function is equivalent to executing a return statement without an expression.). Rwessel (talk) 12:01, 17 February 2013 (UTC)
According to the two clauses that you specified, there *is* an implicit return from main. However, the return value is undefined. Correct me if I'm wrong, but undefined behavior != standards compliant. Tommyinla (talk) 19:05, 17 February 2013 (UTC)
You're quite correct, the value returned from main without an explicit value specifying return is undefined in C89, I was thinking of a slightly different case. But exiting main at the closing brace clearly *is* defined (which should have been my point). In any event, invoking undefined behavior only makes the program not “strictly conforming” (1.7 COMPLIANCE - A strictly conforming program shall use only those features of the language and library specified in this Standard. It shall not produce output dependent on any unspecified, undefined, or implementation-defined behavior, and shall not exceed any minimum implementation limit.). But I don't think this is actually undefined behavior in the usual C sense, rather just the value returned to the host environment (and clearly the program is still defined to successfully return to the host environment, but with some undefined exist status). Any issues the host environment had with that would clearly not be an issue for the C program, which has successfully finished executing. Rwessel (talk) 23:22, 17 February 2013 (UTC)
Interesting point you make. I suppose we can say it's conforming. I did reword the last paragraph of that section though. It specifically stated that 0 was the implicit return value. I modified the verbiage to include, "According to C99 and newer." Tommyinla (talk) 12:16, 18 February 2013 (UTC)

pointer

detail of pointer . — Preceding unsigned comment added by 117.229.112.206 (talk) 14:09, 23 August 2012 (UTC)

Huh? You want us to explain pointers? This is Wikipedia, not a How-To site, unfortunately. --Carrot Lord (talk) 00:32, 20 January 2013 (UTC)
If I understand what you're trying to say, pointers are explained under Pointer (computer programming) Julesmazur (talk) 04:36, 19 February 2013 (UTC)
Alternatively, see this. — Preceding unsigned comment added by Julesmazur (talk • contribs) 15:49, 19 February 2013 (UTC)

SVG version of K&R1 book cover?

Someone has done an SVG of the K&R1 cover, and changed the article to display that. Do we really want a *drawing* of the book cover rather than an actual image? Even though it's fairly close? (The font weights are at least a bit different, for example, but it is close). Rwessel (talk) 12:05, 17 February 2013 (UTC)

"close", but blurred. TEDickey (talk) 13:48, 17 February 2013 (UTC)
Actually, that was me. The original image was very low-res, the name of the publisher was literally unreadable. I can try and make a more accurate version, if you don't want to revert to the low-res raster image. Julesmazur (talk) 04:13, 19 February 2013 (UTC)
I'm wondering if the drawing is really OK at all, policy-wise? I have a K&R1, in passably good condition, I'd be happy to upload a scan, although I'm not sure of the copyright status of that. And if that's a problem, wouldn't that impact the SVG as well? Rwessel (talk) 10:20, 19 February 2013 (UTC)
Well, the original image was out of copyright (in the public domain). With a cover this simple (very little actual design), you also have to consider that certain copyright bureaus might not even grant this kind of design copyright status. Julesmazur (talk) 14:46, 19 February 2013 (UTC)
Here's the original file (I can't get the internal link to display properly). It's "ineligible" for copyright, is in the public domain, and has one banner recommending vector conversion, and another recommending at least dropping the JPEG format. The description is in the wrong language, and the source is Google Books. Julesmazur (talk) 15:05, 19 February 2013 (UTC)

Should this article's "see also" section link to the article on the language itself?

I noticed that the page for The C++ Programming Language links to the article for the C++ language itself, in addition to being linked to from the article's content. Is this redundancy bad practice, to be removed, or should it be implemented in this article as well? Julesmazur (talk) 00:51, 8 March 2013 (UTC)

The C++ Programming Language is a book (of some notability) *about* the language C++ (which has it's own page). As that book in particular discusses the evolution of C++ from C (a different language altogether), a link here seems reasonable. Or did I misunderstand the question? Rwessel (talk) 12:44, 8 March 2013 (UTC)
Note that The C Programming Language book article also links back here. Rwessel (talk) 12:46, 8 March 2013 (UTC)
Let me rephrase: in the article about the book, The C++ Programming Language, there are links to the language itself both in the article, and in the "See Also" section. In the article for the book, The C Programming Language, there are links to C (programming language) in the article, but not in the "See Also" section. This means one of two things: either the links in The C++ Programming Language are redundant, or a link to C (programming language) should be added to the "See Also" section of The C Programming Language for consistency. Julesmazur (talk) 15:29, 8 March 2013 (UTC)

Merge target for C Intermediate Language?

Following up on the recommendation of the closing admin to stage the discussion for CIL merging on this talk page for the AfD Wikipedia:Articles for deletion/C Intermediate Language for the C Intermediate Language article, here is a start on the merge discussion I had created on the C Intermediate Language talk page:

Following up on the good discussion at the recent AfD Wikipedia:Articles for deletion/C Intermediate Language, where should we merge content from this article? The two main target articles mentioned were C programming language and George Necula. While I advocated a little for a particular target, I am mostly interested in (1) preserving the important, verifiable content of this article and (2) making sure that users looking for this information can find it easily. In the interest of consensus, I am happy with CIL being merged to either target article, as long as we put in the other target article a sentence mentioning CIL and a wiki link to the merged material.

What do others think? --Mark viking (talk) 22:28, 29 April 2013 (UTC)

Since it's already mentioned in the "Uses" section that C can be used an intermediate code generation language for various compilers, perhaps a simple expansion of that section is all that is needed. — Loadmaster (talk) 00:40, 30 April 2013 (UTC)

Early developments: how much C-compiler was written in assembler or B prior to C-compiler-in-C

if you read the "early developments" section carefully, it currently describes Unix as having been written in assembler; it does not actually say what the C-compiler was written in, prior to it becoming the compiler for the C language rewrite of Unix. It's an interesting bit of history, ought to be in the article 108.14.121.107 (talk) 21:01, 26 May 2013 (UTC)

c++ as preprocessor

"C++ and Objective-C started as preprocessors for C"-sounds weird, and I cant understand what does it mean "as preprocessors". If its how c++ started, why there is no clue for it in c++ essay? Uziel302 (talk) 22:27, 17 August 2013 (UTC)

The wording is awkward: they were initially preprocessors which read C++/Objective-C source and produced C programs (this was by the way before C was standardized). The C++ topic lacks most of the technical information which would make it interesting, because that is (presumably) covered in the various sources referred to. TEDickey (talk) 22:41, 17 August 2013 (UTC)
The more correct wording is that C++ and Objective C started out as compilers that generated C code (instead of generating assembly code or binary code). While some people did refer to them as "preprocessors", this is misleading and technically incorrect. The first Bell Labs C++ compiler by Stroustrup was named cfront, alluding to the fact that it was a C++ compiler "front end" to the existing C compiler. The way compilers operate is very different from the way preprocessors operate. — Loadmaster (talk) 16:22, 30 September 2013 (UTC)
Eh. It's kind of between the two. C++ Precomprocessorilers don't necessarily change the input at all (except to mangle the function names) and in almost all cases leave most of the source alone. I'm perfectly fine with either term, though, as long as it doesn't thrash back and forth. - Richfife (talk) 19:40, 1 October 2013 (UTC)
Just to be clear, preprocessors do text token manipulations, which is purely lexical processing, but compilers use syntactical and semantic parsing, which includes recognizing data types and managing symbol tables (which add another two or three levels of processing on top of lexical scanning). While the output of both may be pure C, the internal operation of each to generate that output is vastly different. Also, the claim that most of the source code is left alone is simply not true, especially when compiling expressions containing virtual class member function calls, user-defined member operators, object allocations/deallocations, and class vtables, all of which generate fairly complicated intermediate C code. Even the earliest C++ front-end compilers did far more than just mangle names. — Loadmaster (talk) 18:14, 3 October 2013 (UTC)
I don't think the meanings of these terms -- preprocessor and compiler -- are as precise as you make them out to be. Certainly the early C++ engines (for lack of a better term) that generated C did significantly more than the C macro preprocessor, but that doesn't mean it is inappropriate to refer to the C++ engine as a preprocessor of sorts. But the potential confusion with the C preprocessor is concerning.

The term compiler traditionally refers to software that takes high level human-readable source and generates executable code, so these early C++ engines were arguably not compilers, at least not in the traditional sense. You'd have to expand the scope of the term's meaning to apply it to the early engines like cfront. I mean, if the output of a process is something that still requires compiling, the process that produced that output can hardly be called a compiler.

But there should be a way through this semantic minefield that will allow for a clear and unambiguous explanation.

Or this. Cue arguments as to whether C is lower level tier than C++ in 3, 2, 1... - Richfife (talk) 20:27, 3 October 2013 (UTC)

"Hello, world!" program

@Tedickey: Can you please provide a reason for reverting my sourced edit and putting that vandalism notice at my talk? Regards. —ШαмıQ✍ @ 11:51, 25 November 2013 (UTC)

Please allow me to advocate a bit... Function main() is supposed to be returning an int, and character # isn't what indicates an instruction to the compiler. The whole source code is just a bunch of instructions to the compiler, while character # denotes a preprocessor directive. — Dsimic (talk) 13:34, 25 November 2013 (UTC)
Oh yes, I knew about that #, but I used words as written in the book. You could have simply corrected that to preprocessor directive instead of removing the whole thing. And regarding the void: The function main is not supposed to return anything here; why specify the data type, int, then? —ШαмıQ✍ @ 14:05, 25 November 2013 (UTC)

Please note that it wasn't me reverting your edit. Regarding the main()'s return type, here's what the ISO C standard says in section 5.1.2.2.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;[1] or in some other implementation-defined manner.

[1] 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.

With the specified example, it's all about being more close to the standard. — Dsimic (talk) 14:27, 25 November 2013 (UTC)

Ok, you weren't reverting me. But you advocated for Tedickey, and that was why I said so. Well, I get your point, but don't you think void main(void) will be easier for beginners to follow? Not specifying anything might be easier for beginners to understand than specifying the data type of the return value when the function doesn't return anything. —ШαмıQ✍ @ 15:37, 25 November 2013 (UTC)
No worries, I got your point. Let's see what Tedickey is also going to comment there. Also, please have a look at this discussion, in my opinion that would be a much better option — with return instead of exit, of course. — Dsimic (talk) 16:31, 25 November 2013 (UTC)
While "void main()" may be accepted by some compilers (perhaps even most), it is *not* a valid C program per the standard. A sample of an invalid program, which might not even compile on many systems, would make a poor example. Now whether Hello World is actually a good example is a different question, but given its very long history, and particular association with C, including it seems quite reasonable. But then that leads to the immediate issue of having an obsolete form (the original K&R version listed), which also will have problems on many systems, so supplying a modern version would seem necessary. I'm not sure where the second version came from, but as a general concept I would not be opposed to including an explicit "return 0", although that is certainly not required by the standard, and thus would make this not a "minimal" sample (which is what Hello World is supposed to be). If the second form was included, for example, in K&R2 (I'll check my copy of that later today), then that would be an argument for leaving it as-is. But in no case would "void main()" be acceptable as an example. Rwessel (talk) 17:29, 25 November 2013 (UTC)
K&R2 uses the first form. The second is using the C standard, which has been the form used by consensus for quite a while (changing the well-established example to a spurious one which contradicts the standard is an error). TEDickey (talk) 19:46, 25 November 2013 (UTC)
But for beginners, the program must be simple enough (without going into the details of return values). void would simply let the beginner know that there is no return value... Adhering to the standard, the int specification may seem obscure to a novice. I think sacrificing adherence to the standard for just this program, so that the beginner doesn't need to know the technicalities is not a bad deal.—ШαмıQ✍ @ 20:01, 25 November 2013 (UTC)
Again, an incorrect program seems less than helpful. Rwessel (talk) 22:22, 25 November 2013 (UTC)
Interestingly, Hello World did change in K&R2 - they added the include, but did not alter the definition of main. Of course not specifying a return type in this case means the function implicitly returns an int anyway. Rwessel (talk) 22:22, 25 November 2013 (UTC)
no - for beginners it is best to not confuse them with inaccurate information. If you choose to look into the history of this issue, you will note that there are far more reliable sources citing the standard. TEDickey (talk) 20:44, 25 November 2013 (UTC)
I'd sum it up saying that C is specific (and weird) enough that even beginners simply have to reach the point where understanding unobvious things becomes someone's second nature. Having that in mind, int main() explicitly returning nothing is the least weird thing. :) Also, the whole thing with the return value is already described at the end of "Hello, world" section, so it should be good. — Dsimic (talk) 22:48, 25 November 2013 (UTC)
Well, if that is all you want, let it be. But I found void used in quite a few books and figured out that there should be no problem to make it so here. —ШαмıQ✍ @ 05:26, 26 November 2013 (UTC)
sure - for instance Schildt. Be familiar with your topic before making improvements TEDickey (talk) 09:15, 26 November 2013 (UTC)
(edit conflict) Yes, many books do actually get that wrong. That's more a problem of a large number of bad books on C programming. It's an issue of portability - a specific implementation might accept "void main", and even do what you'd hope with it. An implementation *is* free to include an extension like that. But it won't work everywhere. And since this article is about C in general, and not a specific implementation, using that extension in a sample is a problem. Especially if the description of the sample includes the words "standard-conforming." And if we did use an extension in the sample, we'd then be stuck trying to explain where the sample is actually valid. Consider a similar situation with the character set - while the vast majority of C implementations use ASCII, there are certainly some that don't. Including a sample of code that didn't work on a non-ASCII implementation, especially if it was easily avoidable, would just be wrong. Rwessel (talk) 09:35, 26 November 2013 (UTC)
Very well said, second that. — Dsimic (talk) 16:59, 26 November 2013 (UTC)

include-path not in C standard

The before/after edits regarding include-path both have a problem: the C language standard doesn't appear to mention either interpretation, saying of both forms that the file is found in an implementation-defined manner. The way forward is of course to provide a reliable source which identifies the particular behavior in the relevant standard TEDickey (talk) 20:39, 10 March 2014 (UTC)

Totally agreed, please allow me to explain. I've also consulted the ISO C standard while my finger was itching to hit the "revert" link for the initial edit; here's what the 6.10.2 section says:
A preprocessing directive of the form
# include <h-char-sequence> new-line
searches a sequence of implementation-defined places for a header identified uniquely by the specified sequence between the < and > delimiters, and causes the replacement of that directive by the entire contents of the header. How the places are specified or the header identified is implementation-defined.
A preprocessing directive of the form
# include "q-char-sequence" new-line
causes the replacement of that directive by the entire contents of the source file identified by the specified sequence between the " delimiters. The named source file is searched for in an implementation-defined manner. If this search is not supported, or if the search fails, the directive is reprocessed as if it read
# include <h-char-sequence> new-line
with the identical contained sequence (including > characters, if any) from the original directive.
Anyway, instead of reverting I've opted for cleaning up that edit, guided by a thought that in the end it might be more understandable as a description, despite the fact ISO C standard says nothing like that and leaves everything to each specific C implementation.
I have nothing against reverting this back to the original state, as that might be much better than diving into providing references for various implementations. — Dsimic (talk | contribs) 22:48, 10 March 2014 (UTC)
Hm, how about reverting and adding a note containing the above quoted excerpt from the ISO C standard? Can't go wrong with that. — Dsimic (talk | contribs) 22:52, 10 March 2014 (UTC)
offhand, I think that a rough paraphrase of what the C standard says, with a complementary comment about the status in POSIX (or similar, e.g., this) would be helpful to the reader. One thing to watch out for is that the behavior for quoted includes versus bracketed includes differs between implementations, even within the scope of the OpenGroup definition TEDickey (talk) 23:36, 10 March 2014 (UTC)
I agree, I noticed that edit yesterday, and have been trying to come up with a reasonable correction. The original is problematic as well, although not so bad as the new revision. As quoted above, the standard says almost nothing about what gets searched or the difference between #includes with angle brackets or quotes, except that in the case of quotes, if the search fails, it's retried as if it had been specified with angle brackets. The standard headers also must be findable via the angle bracket specification. OTOH, almost all real C implementations do something more like what the text now specifies. It's really not the place to get into a multi-paragraph description of the standardese, OTOH, not saying anything doesn't seem very satisfying either. C preprocessor has more-or-less the same problem. Rwessel (talk) 09:58, 11 March 2014 (UTC)

Hello World Example

I feel that the hello word program should return 0 since this program could fail on some compilers. It's also worth noting that in C99 int main() can be left without a return value at which point it defaults to returning 0, see C99 

#include <stdio.h>

int main(void)
{
    printf("hello, world\n");
    return 0;
}

— Preceding unsigned comment added by LawrencePJ (talk • contribs)

  • I'd also add that the return-less version should not fail on any C89/99/11 compliant compiler. While the value returned is specified only in C99 and later, the return-less form is valid in C89, but the actual value returned to the OS is indeterminate. From the C89 standard:
2.1.2.2 Hosted environment
(...)
Program termination
A return from the initial call to the main function is equivalent to calling the exit function with the value returned by the main function as its argument. If the main function executes a return that specifies no value, the termination status returned to the host environment is undefined.
Rwessel (talk) 18:15, 29 July 2013 (UTC)
Because there are, per the standard, only two allowable forms of main() ("int main(void)" and "int main(int argc, char *argv[])" - or equivalents for the second form). IOW, the only standards conforming versions of main() return int. Section 5.1.2.2.1 of the standard is quoted in the second "Hello world" discussion below, if you're interested. While some implementation might provide/allow a void returning form as an (allowed) extension, support for that is not guaranteed to be universal. Rwessel (talk) 08:30, 19 December 2013 (UTC)
Those things are 'peccata minuta', the return statement is important to the os/shell. It is a good discipline to write programs portable and unambiguous.
It is a bad practice to omit type declarations or to depend on some default value which may not be portable. The same applies, for example, to programs which may change their meaning due to endianess, word size, etc. A careful programmer may use pragmas, conditional compilation and macros, to define new data types which ensure the portability of the program to other architectures and OSes. — Preceding unsigned comment added by 189.178.35.11 (talk) 05:40, 23 April 2014 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:C_(programming_language)/Archive_14&oldid=851067806"