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

Revision as of 00:02, 17 August 2022

Latest revision as of 12:09, 28 July 2025

(12 intermediate revisions by the same user not shown)

Line 129:

I started to revise the text about arrays because it was outdated, slightly incorrect, and partially misleading. (As background info: I am a member of the ISO working group for C and contributor to GCC.) [[User:Martin.uecker|Martin.uecker]] ([[User talk:Martin.uecker|talk]]) 08:25, 21 November 2021 (UTC)

== Italics ==

{{ping|Chumpih}} I don't think [[MOS:TERM]] applies to [[Special:Diff/1083919386|this edit]]. It says {{tq|A technical or other jargon term being introduced is often being mentioned as a word rather than (or in addition to) playing its normal grammatical role}}, but in this case it is neither a technical term (rather, it is a proper name) nor is it being mentioned as a word. If the name of the language were 'Python' rather than 'B' I doubt anyone would write "A successor to the programming language ''Python''". [[User:Rublov|Ruбlov]] <small>([[User talk:Rublov|talk]] • [[Special:Contributions/Rublov|contribs]])</small> 15:25, 21 April 2022 (UTC)

:@[[User:Rublov|Rublov]], Given these are the introductions of the terms, as opposed to references to the terms, perhaps the italicisation is warranted. [[User:Chumpih|<span style="text-shadow: 2px 2.5px 3px #448811bb">Chumpih</span>]] ^{[[User talk:Chumpih|t]]} 15:41, 21 April 2022 (UTC)

::Actually, on further consideration, you're probably right. Apologies. [[User:Chumpih|<span style="text-shadow: 2px 2.5px 3px #448811bb">Chumpih</span>]] ^{[[User talk:Chumpih|t]]} 16:00, 21 April 2022 (UTC)

== Order of sentences in the opening paragraph ==

Is there a good reason why the opening paragraph starts with “commonly in …” then one “decreasingly in …” then more “commonly in …”? I found this order slightly confusing. [[User:Osalbahr|Osalbahr]] ([[User talk:Osalbahr|talk]]) 01:39, 31 May 2022 (UTC)

: It's likely imperfect, as you identify. [[WP:DIY]]. Then perhaps [[WP:BRD]] or perhaps subsequent changes if your edits don't quite hit the mark. [[User:Chumpih|<span style="text-shadow: 2px 2.5px 3px #448811bb">Chumpih</span>]] ^{[[User talk:Chumpih|t]]} 21:24, 31 May 2022 (UTC)

== "C(programming language)" listed at [[Wikipedia:Redirects for discussion|Redirects for discussion]] ==

[[File:Information.svg|30px]]

An editor has identified a potential problem with the redirect [[:C(programming language)]] and has thus listed it [[Wikipedia:Redirects for discussion|for discussion]]. This discussion will occur at [[Wikipedia:Redirects for discussion/Log/2022 August 16#C(programming language)]] until a consensus is reached, and readers of this page are welcome to contribute to the discussion. <!-- from Template:RFDNote --> [[User:Steel1943|<span style="color: #3F00FF;">'''''Steel1943'''''</span>]] ([[User talk:Steel1943|talk]]) 21:09, 16 August 2022 (UTC)

== A Commons file used on this page or its Wikidata item has been nominated for speedy deletion ==

The following Wikimedia Commons file used on this page or its Wikidata item has been nominated for speedy deletion:

* [[commons:File:1999 ISO C.pdf|1999 ISO C.pdf]]<!-- COMMONSBOT: speedy | 2022-08-18T19:08:46.320875 | 1999 ISO C.pdf -->

You can see the reason for deletion at the file description page linked above. —[[User:Community Tech bot|Community Tech bot]] ([[User talk:Community Tech bot|talk]]) 19:08, 18 August 2022 (UTC)

== popularity contests ==

A recent edit confuses ''popularity'' (a weakly-defined, subjective term) with ''widely-used''. Sources such as the two most recently proposed are unconvincing [[User:Tedickey|TEDickey]] ([[User talk:Tedickey|talk]]) 22:05, 1 August 2022 (UTC)

: I consider that the newly added claim ("though decreasingly") has no place in the lead: it only makes it longer by stating a dubious and unsourced perception. Blog sources shouldn't even be considered, per [[WP:RS]]. The article, and in particular its opening paragraph, should describe the language throughout its entire existence, not "C nowadays" or "C in recent years", per [[MOS:RELTIME]]. [[User:Fbergo|Fbergo]] ([[User talk:Fbergo|talk]]) 22:26, 1 August 2022 (UTC)

::so perhaps we could have {{tq| previously for application development}} ? Point being that there doesn't appear to be evidence to suggest that C remains widespread for that purpose, former glories notwithstanding. [[User:Chumpih|<span style="text-shadow: 2px 2.5px 3px #448811bb">Chumpih</span>]] ^{[[User talk:Chumpih|t]]} 22:58, 1 August 2022 (UTC)

::: "It has found lasting use in operating systems, device drivers, protocol stacks, and application software". Lasting refers to the duration of usage of the language in each software product/project, not that the use is widespread or prevalent. [[GIMP]], the open source graphics editor, is written and maintained in C since 1998. GIMP alone serves as refutation to "C is no longer used for application development" or "C found use for application development in the past, but not recently", even though many other examples certainly exist, but are hard to track as most commercial applications do not advertise or expose their programming language. [[User:Fbergo|Fbergo]] ([[User talk:Fbergo|talk]]) 23:41, 1 August 2022 (UTC)

::::Well, it's a good point: GIMP desktop application project started 24 years ago did indeed choose C as the implementation language, and that application has proven excellent and popular. And prior to [[Microsoft Visual C++|Visual C++]] (1993) a lot of significant Windows application programming was done ''[[Charles Petzold|Petzold]]'' style, using C almost exclusively. Here's the thing - for {{tq|device drivers, protocol stacks, operating systems, embedded systems, utilities}}, C remains a solid player; for applications, not so much. We should differentiate - hence some language like {{tq|formerly in applications}} or {{tq|decreasingly in applications}} when noting C's use in these fields. And that includes applications on web, mobile, desktop, smart TV. There are a few areas where C remains popular for applications, e.g. Automotive, and yes, GIMP is glorious. But they're in the minority. Nobody is stating {{!tq|"C is no longer used for application development"}}, but C's use in applications has decreased massively since the 1990's. Even [[Qt (software)|Qt]] is in C++. Some evidence on language choice for contemporary development is [https://madnight.github.io/githut/#/undefined/undefined/1 here]. [[User:Chumpih|<span style="text-shadow: 2px 2.5px 3px #448811bb">Chumpih</span>]] ^{[[User talk:Chumpih|t]]} 06:09, 15 August 2022 (UTC)

: {{ping|Tedickey}} It's not certain that ''widely used'' is a well-defined term, either. The 'popularity' measure from Tiobe is a well-recognised attempt to show the trends in program language momentum / traction / funding or whatever. Now, here's the problem: any statistic can be questioned. For example, [https://madnight.github.io/githut/#/undefined/undefined/1 Git hub languages trends for pull requests] is only for open-source, or it's too web-specific, or it's just for hobbyists. Recent links that show C absent from 'popular language for desktop application development' are deemed unsubstantive. So to turn this on its head, is any information available to show that C remains comparatively popular for application development? [[User:Chumpih|<span style="text-shadow: 2px 2.5px 3px #448811bb">Chumpih</span>]] ^{[[User talk:Chumpih|t]]} 22:50, 1 August 2022 (UTC)

::Reliable sources are verifiable. Adding comments which are not verifiable doesn't go in the right direction. [[User:Tedickey|TEDickey]] ([[User talk:Tedickey|talk]]) 07:47, 18 August 2022 (UTC)

:::Hmmm. Wise words. So where does that leave us? [[User:Chumpih|<span style="text-shadow: 2px 2.5px 3px #448811bb">Chumpih</span>]] ^{[[User talk:Chumpih|t]]} 08:21, 18 August 2022 (UTC)

::::In the absence of any comments or evidence to the contrary, or any evidence-based retort to comments from a few weeks ago, perhaps the 'dubious' tag can be removed. [[User:Chumpih|<span style="text-shadow: 2px 2.5px 3px #448811bb">Chumpih</span>]] ^{[[User talk:Chumpih|t]]} 22:35, 3 September 2022 (UTC)

== Pointers to pointers ==

I'm starting this discussion because of the ongoing edit war. I think we can agree that the section on pointers doesn't need a full example showing the use of pointers-to-pointers or a subsection just for pointers-to-pointers. At the same time, I think sentence or two pointing out that pointers-to-pointers are a thing would be nice. There are similar sentences talking about void pointers, character pointers and struct pointers already. @[[User:Fbergo|Fbergo]] @[[User:Pmk456|Pmk456]] What do you guys think? [[User:Erinius|Erinius]] ([[User talk:Erinius|talk]]) 22:50, 5 October 2022 (UTC)

: Hi, the added section (which I removed) appears to be an attempt to promote a link to a particular course as a citation, so [[WP:CITESPAM]]. The language in which it was written is inadequate for Wikipedia ("when we declare a pointer to pointer...": We?). A short sentence about pointers to pointers could be added to the Pointers section, but I think this article does not need any more code examples. [[User:Fbergo|Fbergo]] ([[User talk:Fbergo|talk]]) 11:43, 6 October 2022 (UTC)

::Yeah, the language was inadequate and the whole subsection was a bit excessive. Thanks for the feedback, I added in a short little sentence which should be fine. [[User:Erinius|Erinius]] ([[User talk:Erinius|talk]]) 17:35, 6 October 2022 (UTC)

== Delete the K+R example code ==

Should we delete the example of K+R C with the commented-out {{code|int}} types? Perhaps an example of this isn't necessary. Also, having recently looked at a first edition "C programming language", the function definitions and declarations include {{code|int}}, even though it may not be strictly required. [[User:Chumpih|<span style="text-shadow: 2px 2.5px 3px #448811bb">Chumpih</span>]] ^{[[User talk:Chumpih|t]]} 19:56, 12 October 2022 (UTC)

: I'd rather keep the example, as it is of historical interest on the development of the language and integrates well with the section text around it. The code comments are a bit too verbose, and could probably be shortened a little. [[User:Fbergo|Fbergo]] ([[User talk:Fbergo|talk]]) 00:58, 13 October 2022 (UTC)

::Indeed, the comments are too much. But the concern is that this is the first significant example in the text, and it shows code that while technically acceptable to some early versions of the compiler, it is not idiomatic and representative of examples that would appear in K+R. The fact that the {{code|int}} type was once optional in the first version perhaps doesn't warrant an example.

::Or if there should be an example of early-style C code, perhaps one illustrating the function argument typing method would be more appropriate, i.e. arguments and types come on lines after the function name in the definition. [[User:Chumpih|<span style="text-shadow: 2px 2.5px 3px #448811bb">Chumpih</span>]] ^{[[User talk:Chumpih|t]]} 09:10, 22 October 2022 (UTC)

==Wiki Education assignment: Linguistics in the Digital Age==

{{dashboard.wikiedu.org assignment | course = Wikipedia:Wiki_Ed/University_of_Arizona/Linguistics_in_the_Digital_Age_(Spring_2023) | assignments = [[User:ManD01n|ManD01n]] | start_date = 2023-01-11 | end_date = 2023-05-11 }}

<span class="wikied-assignment" style="font-size:85%;">— Assignment last updated by [[User:Nurbekyuldashov|Nurbekyuldashov]] ([[User talk:Nurbekyuldashov|talk]]) 01:52, 9 May 2023 (UTC)</span>

== Delete the "middle-level language" part ==

It's bound to cause confusion on to the nature of C as somewhere between a high-level and low-level language, especially since [[Low-level programming language#Assembly language|Low-level programming language #Assembly language]] names it as a high-level language. One could also argue that middle-level is a fairly vague term that could have a lot of different interpretations. [[User:Gvv57348|Gvv57348]] ([[User talk:Gvv57348|talk]]) 18:06, 11 December 2022 (UTC)

:[[WP:DIY]] You may have a good point, IMHO. [[User:Chumpih|<span style="text-shadow: 2px 2.5px 3px #448811bb">Chumpih</span>]] ^{[[User talk:Chumpih|t]]} 20:14, 11 December 2022 (UTC)

:

::BTW, WP has articles [[Low-level programming language]] and [[High-level programming language]], but no such thing for middle level (this could have possibly been [[WP:OR]]). — [[User:Vincent Lefèvre|Vincent Lefèvre]] ([[User talk:Vincent Lefèvre|talk]]) 14:13, 12 December 2022 (UTC)

:::The only way you can @[[User:Gvv57348|Gvv57348xv]] has [[Special:Contributions/108.75.76.176|108.75.76.176]] ([[User talk:108.75.76.176|talk]]) 04:17, 14 May 2023 (UTC)

== 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>]] ^{([[User talk:Dylnuge|''Talk'']] • [[Special:Contributions/Dylnuge|''Edits'']])} 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/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>]] ^{[[User talk:Chumpih|t]]} 20:18, 8 November 2023 (UTC)