View source for Talk:C (programming language)

{{Skip to talk}}
{{Talk header|search=no|noarchive=yes}}
{{WikiProject banner shell|class=C|vital=yes|1=
{{WikiProject Computing |importance=Top |software=y |software-importance=Top |science=y |science-importance=High}}
{{WikiProject Computer science |importance=High}}
{{WikiProject C/C++ |importance=Top |c=yes}}
}}
{{ArticleHistory
|action1=FAC|action1date=2004-03-15, 02:35:04 |action1link=Wikipedia:Featured article candidates/C (programming language)|action1result=promoted|action1oldid=2774835
|action2=FAR|action2date=2006-07-25, 12:59:24 |action2link=Wikipedia:Featured article review/C (programming language)|action2result=removed|action2oldid=65748965
|action3=GAN|action3date=2006-09-09, 00:06:07 |action3link=Talk:C (programming language)/GA1 |action3result=failed|action3oldid=74539171
|currentstatus=FFA
}}
{{annual readership}}
{{afd-merged-from|C Intermediate Language|C Intermediate Language|29 April 2013}}
{{User:MiszaBot/config
|archiveheader = {{talk archive navigation}}
|maxarchivesize = 31K
|counter = 17
|minthreadsleft = 4
|minthreadstoarchive = 1
|algo = old(100d)
|archive = Talk:C (programming language)/Archive %(counter)d
}}
{{archives|bot=MiszaBot I|search=yes|age=100|dounreplied=yes}}



== C is a system language, not general purpose ==

C has system facilities. Any language with low-level facilities should not be use for general-purpose programming. It bakes in dependencies, results in lock in (which C does), and also results in inflexibility.

C also has many primitive facilities like pointers and defines which really have no place in general-purpose programming. [[User:Ian.joyner|Ian.joyner]] ([[User talk:Ian.joyner|talk]]) 20:12, 13 May 2023 (UTC)

:I see you put this on [[Talk:C++]] as well; it is generally wrong, and I'll reply to both comments here. [[General-purpose programming language]] is a specific term contrasted with domain-specific languages. C is a general-purpose programming language and you will find this present in nearly any source that discusses it. For instance, the very first sentence of K&R (2nd ed.) says "{{tq|C is a general-purpose programming language.}}" (page 1; also a near identical sentence is in the preface on p. xi).
:The Uses section is a mess and needs some serious cleanup, but it's valid to discuss how it is used; C is widely used outside of systems programming contexts, though, so this change would also be invalid there. Wikipedia is an encyclopedia and [[WP:NOTMANUAL|not a manual]]; it would be inappropriate for the article to present an opinion on where C should be deployed in wiki-voice.
:It ''might'' be appropriate to present opinions on current usage of C (and C++, in that article). There are several experts in the field who have expressed concerns specifically related to memory safety with the wide deployment of programs written in C and C++—this is far from a universally held opinion though. Note that this would require more research to incorporate; my off-the-cuff anecdote isn't enough, and any change would want to assess appropriate sources (ideally, highly trustworthy secondary sources, especially ones that provide general overviews of the state of the art, such as instructional textbooks). [[User:Dylnuge|<span style="color: #1e79a1;font-weight:700;">Dylnuge</span>]] <sup>([[User talk:Dylnuge|''Talk'']] • [[Special:Contributions/Dylnuge|''Edits'']])</sup> 17:29, 1 September 2023 (UTC)

== "Only the last member stored is valid" ==

In the "overview" section, under "User-defined (typedef) and compound types are possible" Unions are mentioned as "Union is a structure with overlapping members; only the last member stored is valid."

This is not a fair or accurate statement according to the C standard. I believe this may have been written confusing the C standard for the C++ one, in which accessing a union member that was not most recently written to is strictly undefined.

The C standard explicitly allows "type-punning" using unions, but carefully promises that reinterpreting the bit-representation of one type to another may result in an invalid or trap representation.

The following is pulled directly from the C17 standard. It lies in a footnote under section 6.5.2.3.3:

"If the member used to read the contents of a union object is not the same as the member last used to store a value in the object, the appropriate part of the object representation of the value is reinterpreted as an object representation in the new type as described in 6.2.6 (a process sometimes called “type punning”). This might be a trap representation."

The mention of unions should probably be edited to something like "Union is a structure with overlapping members; it allows multiple data types to share the same memory location".

I will leave this note here for a few weeks and if no one objects I will make the edit. [[User:WillisHershey|WillisHershey]] ([[User talk:WillisHershey|talk]]) 21:28, 25 September 2023 (UTC)

== improving the "hello world" example ==

Rather than an blind "afaik", a [[WP:RS|reliable source]] is needed to alter an example which has a valid reliable source.  [[User:Tedickey|TEDickey]] ([[User talk:Tedickey|talk]]) 10:15, 22 October 2023 (UTC)

:'''Give in''': Meanwhile, I checked the program using gcc 11.4.0 under Ubuntu. It seems the a missing <code>return</code> leads to a warning - ''except'' in <code>main()</code>, so {{u|Tedickey}} is right. As a side remark, I don't see a source given for the 2nd version. - [[User:Jochen Burghardt|Jochen Burghardt]] ([[User talk:Jochen Burghardt|talk]]) 10:21, 22 October 2023 (UTC)

::Quoting from ''ISO/IEC 9899:1999(E)'', section 5.1.2.2.3 '''Program termination''':
<blockquote>If the return type of the main function is a type compatible with int, 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; reaching the '''}''' that terminates the main function returns a value of 0.
</blockquote>
::Perhaps C11 changes that, but again, a [[WP:RS]] helps [[User:Tedickey|TEDickey]] ([[User talk:Tedickey|talk]]) 15:19, 22 October 2023 (UTC)

::Regarding the comment that a diagnostic is required: I don't see that in the standard.  Perhaps it's another instance of people confusing a particular implementation with the standard [[User:Tedickey|TEDickey]] ([[User talk:Tedickey|talk]]) 15:35, 22 October 2023 (UTC)

== Mention of C allowing various memory allocations schemes ==

{{u|Jochen Burghardt}} [https://en.wikipedia.org/enwiki/w/index.php?title=C_(programming_language)&diff=prev&oldid=1183993545 removed] this section on C allowing various memory allocation implementations:

:{{tq|C permits the use and implementation of different [[C dynamic memory allocation|memory allocation]] schemes, including a typical {{code |lang=c |malloc}} and {{code |lang=c |free}}; a more sophisticated mechanism with [[Region-based memory management|''arenas'']]; or a version for an [[kernel (operating system)|OS kernel]] that may suit [[direct memory access|DMA]], use within [[interrupt handler]]s, or integrated with the [[virtual memory]] system.}}

With the edit summary {{tq|"malloc is not built in in C, but a library function, and could be provided for every other language in a similar way"}}. It's actually not true that you can do this in every other language, it depends on directly manipulating and storing pointers for one thing, which most languages do not do. The passage doesn't say malloc is part of C itself, in fact it implies the opposite - it lists malloc as one possibility. I disagree with this removal. [[User:DIYeditor|—DIYeditor]] ([[User talk:DIYeditor|talk]]) 19:49, 7 November 2023 (UTC)

:As I understand the title of this article, it is about the C programming language itself; there is a different article [[C standard library]]. "{{tq|The passage doesn't say malloc is part of C itself}}" - this is the reason why I think it shouldn't be discussed here, but at [[C standard library]]. As a side remark, <code>malloc</code> can be implemented as is in every language that supports pointers, and with slight modifications in every language that supports arrays (having arbitrary type casts in the language will increase user convenience). - [[User:Jochen Burghardt|Jochen Burghardt]] ([[User talk:Jochen Burghardt|talk]]) 11:58, 8 November 2023 (UTC)
::Please stop edit warring to restore your preferred version.
::We can wait for input from more people. [[User:DIYeditor|—DIYeditor]] ([[User talk:DIYeditor|talk]]) 13:17, 8 November 2023 (UTC)
:::I didn't edit [[C (programming language)]] after my above reply. The anonymous IP 193.162.48.193 vandalized an article part that is unrelated to our above discussion, and I assure that it wasn't me. Admittedly, my 2nd revert might have violated a strict interpretation of [[WP:BRD]]; however, I gave a long justification in my edit summary. Waiting for opinions from other people is ok for me. - [[User:Jochen Burghardt|Jochen Burghardt]] ([[User talk:Jochen Burghardt|talk]]) 14:05, 8 November 2023 (UTC)
::The goal of this the overall section is to explain and justify the wide adoption of C as a  systems programming language.  The section in question states that C permits choice in dynamic memory allocators - a good justification, since operating systems and similar often control memory for other processes.  Options range from the usual {{code|stdlib.h}} to very machine-specific ones.   This flexibility is a feature of the language.  Only one of the choices pertains to the standard library and its {{code|malloc}} - the others do not - and indeed there is already a link in the debated section to [[C dynamic memory allocation]].  
::If there are improvements to be made, then let's make them!  But I agree with {{u|DIYeditor}} and disagree with the removal. [[User:Chumpih|<span style="text-shadow: 2px 2.5px 3px #448811bb">Chumpih</span>]] <sup>[[User talk:Chumpih|t]]</sup> 20:18, 8 November 2023 (UTC)

== obobobobooboboboboboboobooibooboboboob ==

ddgtcdfsgdccdgddfffhxffffffcodehddgtgdgjdhtfygtfh gvcb hb  vvfvf frb [[Special:Contributions/2600:1700:1F7D:DC00:AEA0:127B:402E:FCA0|2600:1700:1F7D:DC00:AEA0:127B:402E:FCA0]] ([[User talk:2600:1700:1F7D:DC00:AEA0:127B:402E:FCA0|talk]]) 21:31, 25 March 2024 (UTC)