Talk:C (programming language)/Archive 11: Difference between revisions

Revision as of 17:00, 15 April 2023

Latest revision as of 17:25, 1 October 2024

Line 21:

:::This will compile without errors or warnings, making C a weakly typed language — a strongly typed one will either not allow this, or throw an exception at runtime. C can't even be strongly typed, because it has a weak type system and lacks any concept of "objects" and associated type information at runtime. By the way, I found an excellent explanation here: [http://stackoverflow.com/questions/430182/is-c-strongly-typed Is C strongly typed?]. [[User:Adrianwn|Adrianwn]] ([[User talk:Adrianwn|talk]]) 09:28, 30 December 2009 (UTC)

::::I'll concede the point, but it should be noted that those kinds of conversions are ''only'' allowed for conversions to and from void pointer values. Assigning a <ttcode>float</ttcode> value to a pointer, for example, is illegal. — [[User:Loadmaster|Loadmaster]] ([[User talk:Loadmaster|talk]]) 19:06, 1 January 2010 (UTC)

== websites can also be programmed in C ==

Line 110:

The '''"%s"''' must be included to avoid a [[Format string attack]]. Please, discuss... [[Special:Contributions/83.55.41.191|83.55.41.191]] ([[User talk:83.55.41.191|talk]]) 21:38, 1 January 2010 (UTC)

:After reading that article and a cursory glance at [http://julianor.tripod.com/bc/formatstring-1.2.pdf this], I believe the vulnerability is present only when you pass "unfiltered user input" directly to these functions as format strings, as in <ttcode>printf(buffer);</ttcode> where the string <ttcode>buffer</ttcode> gets its value during runtime by user input. In the case of "hello world\n", the simple string "hello world\n" is constant, doesn't contain harmful characters and cannot be altered by user input; so its safe. Instead of "hello world\n" were it the string "%s%s%s%s%s%s%s%s%s%s%s%s", the program would crash (this particular example is from the pdf linked above). --[[User:Zvn|Zvn]] ([[User talk:Zvn|talk]]) 22:36, 1 January 2010 (UTC)

:I have not read the linked page but the point is fairly obvious to hard core coders. There is clearly no problem with the current article, and I do not think we need be concerned with providing a full set of best practices, so I do not think any change is needed. [[User:Johnuniq|Johnuniq]] ([[User talk:Johnuniq|talk]]) 03:54, 2 January 2010 (UTC)

Line 132:

One text I read suggested a way to avoid this error: Keep a constant to the left of a variable. Whereas "if (3 == userChoice)" is just as good as "if (userChoice == 3)" for a comparison, using "if (3 = userChoice)" will always result in an assignment error. It's brilliantly simple . . . but I could never develop the habit of writing those expressions "backwards"! [[User:WHPratt|WHPratt]] ([[User talk:WHPratt|talk]]) 19:00, 29 December 2009 (UTC)

:Yes. While it's somewhat common in some circles to see expressions such as <ttcode>NULL</ttcode>&nbsp;<ttcode>==</ttcode>&nbsp;<ttcode>p</ttcode>, I personally find it hard to read, having a backwards literal reading to normal English logic (''"Null is equal to pointer p"'' instead of ''"Pointer p is null"''). Perhaps the article should have a sentence or two about this programming idiom. — [[User:Loadmaster|Loadmaster]] ([[User talk:Loadmaster|talk]]) 19:23, 29 December 2009 (UTC)

::The article should not attempt to cover programming style, or it would grow way too large. Also, such matters are disputable; for example, I agree that it is harder to read the "safer" form described by WHPratt above. Frankly, I know of no experienced C programmer who makes the cited mistake, so it's totally unnecessary to contort the natural form of expression. — [[User:DAGwyn|DAGwyn]] ([[User talk:DAGwyn|talk]]) 02:38, 13 May 2010 (UTC)