Talk:C (programming language)

"Standard conforming"? What standard

To what lengths are we going to implement "standard"s? Somewhere in comments about various entries in the Underhanded C Contest (website http://underhanded.xcott.com/) there is the point that the "printf" of "hello, world" should be:

   printf("%s", "hello, world\n")
or 
   printf("%s\n", "hello, world")

Old_Wombat (talk) 11:37, 25 April 2011 (UTC)

Gonna need a more specific citation than an entire website. --Cybercobra (talk) 14:05, 25 April 2011 (UTC)

That claim is made occasionally, it's not correct. It *is* a very bad idea to pass in an unknown format string to printf(). Thus ps="hello, world"; ... printf(ps); is risky if you don't know for sure that ps points to a valid format string. And if the string to be printed contains any escapes("%") that printf will try to interpret, it requires special care to pass as the first parameter. But obviously neither of those apply in this case. Rwessel (talk) 15:57, 25 April 2011 (UTC)

Let's just use "Hello World" as it first appeared and go about our day. I'm sure we can all write hundreds of valid variants ("Let's find a Taylor Series that generates those ASCII codes!", "I can do it in 27 characters!", etc.) and arguing over which one is the best is no more likely to get anywhere than arguing over bracket placement or byte-ordering. - Richfife (talk) 17:35, 25 April 2011 (UTC)

It's funny just how often "Hello World" debates crop up, isn't it? Sort of like debating about which direction to put the shirt on the hanger—should we *really* spend so much time arguing about such trivial things? Jeez. Sebastian Garth (talk) 03:07, 26 April 2011 (UTC)

I'm a toilet-paper-rolls-to-the-front kind of person myself. The string "Hello, world\n" is not an unknown format string; the programmer can see every character in it in the call to printf(). Let's just leave the original Hello, world example the way it is in the original white book, shall we? — Loadmaster (talk) 02:42, 13 August 2011 (UTC)

An even more pedantic point

There is NO SUCH THING as a "curly brace" or for that matter "square bracket". There are:

parentheses: ( )

brackets: [ ]

braces: { }

Old_Wombat (talk) 11:43, 25 April 2011 (UTC)

Basis for your claim? --Cybercobra (talk) 14:07, 25 April 2011 (UTC)

Here's "a" basis for such a claim: The C Programming Language (Brian W. Kernighan, Dennis M. Ritchie, Prentice-Hall, 1978). In the description of the first "hello, world" program, (p4) "The braces { } enclose the statements that make up the function; ..." First mention of "bracket" in connection with use in a C program. Not "first ever", but likely the first in book form. Also, in the REAL standard prior to 1998, C A Reference Manual (Samuel P. Harbison, Guy L. Steele, Prentice-Hall, 1984) Section 7.3.4(p.146) begins, "A subscripting expression consists of a primary expression, a left bracket, an arbitrary expression, and a right bracket."

Also, in the standards: Nowhere in the C99 (draft as of 1998) or C++ 1998 ISO 14882 standards does the word "curly" occur in any context, much less as "curly brace". Braces is braces. The term "square bracket" occurs once only in the C99 draft, in the context previously mentioned (below) at 6.5.2.1. I don't have a copy of C98 to look at, but it's curious that the corresponding paragraph in C++1998 reads the same...but that makes a bit of sense because < > are used as "angle brackets" in C++. Nowhere else in either document does "square bracket" occur.

As for the Unicode Database, "left/right bracket", and "left/right brace" are also listed names for { } [ ] respectively. I don't know about modern standards, but the mathematical use in secondary school in the 1960s and college in the 1970s was "parenthesis", "bracket" and "brace"; in order of preference as a grouping symbol. Math usage in those days influenced more computer language than did typography, which is the basis for the Unicode Character Database. We're discussing C, which has "functions", not "procedures", after all. — Husoski (talk) 00:44, 12 July 2011 (UTC)

You're arguing for the common (programmer's) informal names of the characters, and against the international standard names for them. In a source like Wikipedia, it's more appropriate to use the standard nomenclature. The informal names can be mentioned, but they obviously don't carry the same authoritative weight that the official terminology does. — Loadmaster (talk) 19:28, 13 July 2011 (UTC)

No, I am not. In fact, I supported the original assertion with references for the names of these symbols as used in C. The Wikipedia entry on poker describes certain card holdings as "straights" or "straight flushes", even though the same group of cards in other card games is called a "run" or "run in suit".

I am arguing for using C sources for C terminology. I do not consider the Unicode Character Database as a definition of symbol names as used in C. The UCD has no authority regarding the naming of symbols as used in C. For example, the primary UCD name for the \ character is "REVERSE SOLIDUS". (Yes, these are all caps in the UCD.) However, in C it is a backslash. If the UCD were to disagree, it would be the UCD that were in error--just as it would be if a Wikipedia entry said the same thing. The correct approach, IMHO, is to mention other names for the symbols as used in other contexts--if that's required at all--rather than to obscure the C usage in an article about C. "Square bracket" has some justification, just barely, in the C literature. "Curly brace", on the other hand, does not appear to have serious support. UCD notwithstanding. — Husoski (talk) 22:49, 13 July 2011 (UTC)

Bracket points out that all three terms are ambiguous depending on the speaker (for example, British common usage of "bracket" is equivalent to US parenthesis), and lists "square bracket" and "curly brace" as known variants. In fact "bracket", in terms of punctuation, properly refers to the whole class of symbols (( ), [ ], { }, < >...).

Note that the C standard itself uses “bracket” in the general sense in places (6.7.8 “30 Note that the fully bracketed and minimally bracketed forms of initialization are, in general, less likely to cause confusion.” - referring to the use of curly braces in initializations), and qualifies “bracket” in other places (6.5 “71 … subscripting brackets []”, “6.5.2.1 Array subscripting … 2 A postfix expression followed by an expression in square brackets []”). Rwessel (talk) 16:12, 25 April 2011 (UTC)

The ISO standard name for the "{" character is left curly bracket; that is also the standard Unicode name for it, as well as opening curly bracket, and left brace. Likewise, the standard name for "[" is left square bracket, as well as opening square bracket. See the Unicode code chart. The Hacker's Dictionary entry for ASCII is also illuminating on this point. — Loadmaster (talk) 16:33, 28 April 2011 (UTC)

I happen to believe that parenthesis, bracket, brace is the One True Naming Convention for these glyphs, but since the British don't even know what a parenthesis is, there's no way that Wikipedia will ever be the place for it. The terms that best enable the full spectrum of international and non-technical users here to immediately grasp what's being talked about are what should be used here. —chaos5023 (talk) 20:50, 13 July 2011 (UTC)

Related ... kind of ... not ...

Section Related languages shoots itself in the foot regarding Python:

has a different sort of C heritage. While the syntax and semantics of Python are radically different from C, the most widely used Python implementation, CPython, is an open source C program. This allows C users to extend Python with C, or embed Python into C programs ...

which is nonsense. The text claims that it has a heritage, then no heritage at all (confusing "implemented in" with "inheriting from"), then alleging a diversity of connections that has nothing to do with "heritage" as proof of heritage.

The fact is that Python has no heritage from C at all. I propose removing it. Rursus dixit. (^mbork³!) 15:10, 14 June 2011 (UTC)

No, I propose rewriting it, making a subsection of C-implemented languages. They don't inherit, they peruse. Rursus dixit. (^mbork³!) 15:23, 14 June 2011 (UTC)

As Python has been removed from the related languages section, should it also be pulled from the "influenced" section of the infobox (and the back link from the Python infobox)? Rwessel (talk) 01:15, 15 June 2011 (UTC)

Terminating strings with a NUL

The Criticism section has a new "terminating strings with a NUL" criticism with a bare link to a blog (which I only skimmed very quickly). My feeling is that the criticism is undue given C's history, and poorly expressed (the extra compiler cost is related to some cases where the compiler may be able to optimize the code, so the current wording is a bit off). The key point about the original terminate-with-NUL decision was that C has no built-in limit to the length of a string, something that I did not see discussed in the blog in my quick skim—the blog seems to suggest that adding a single extra byte to make a byte count field of two bytes would have been a better choice (i.e. have a two-byte length instead of a one byte terminator). That is just misguided, and four bytes is far too many for embedded controllers or indeed many applications at the time C was developed. A better criticism would be that C's strings cannot contain arbitrary data. I don't feel strongly enough to remove the new text myself, but wonder if anyone has comments, or a better source. Johnuniq (talk) 00:06, 13 August 2011 (UTC)

I found the source to be extremely biased though valid on a few points- namely security issues. I trimmed the comments somewhat, but I don't think the portions about the hardware, compiler, or performance costs are actual issues, but more of a sensationalism. The problem with the compiler costs argument is two fold:

1. The article makes no claim about what the vast number of optimizations that need to be done due to NUL-terminators.
2. The article doesn't quantify development cost or really say anything other than that NUL-terminators increase compiler development costs.

As for performance costs:

1. The article didn't quantify this other than to say bcopy/memcpy can be implemented more efficiently by copying word size chunks as opposed to byte size. This may well be true, but it is stated without any proof.

As for hardware costs:

1. Doesn't quantify hardware costs.
2. The article basically says that older systems using the addr+len model had ISA support for it. Then gives an example of another system having to add string NUL-terminator HW support. How is the latter more costly than the former?

More or less, if you examine what the article says, none of it really holds up. The problem here is that it appears to be mostly an opinion piece. I was troubled with removing it completely because the article is ACM though and appears to be a valid source that would probably be controversial to remove without discussion. Personally, I feel we should clobber it though if other editors agree. Or rewrite it into criticisms of string security w.r.t. buffer overruns.  snaphat ► 01:17, 13 August 2011 (UTC)

Return 0 Status

Should we add that 'return 1' indicates a failure as in for example, bad user input,etc? It will give some contrast to the 'return 0' line of code and explain the difference between returning 0 and 1(or any non zero integer) more clearly. 07:05, 23 August 2011 (UTC)