Jump to content

Talk:C (programming language)

Page contents not supported in other languages.
Add topic
From Wikipedia, the free encyclopedia
Latest comment: 4 days ago by Johnuniq in topic month[11] vs. month[12]
Former featured articleC (programming language) is a former featured article. Please see the links under Article milestones below for its original nomination page (for older articles, check the nomination archive) and why it was removed.
Article milestones
DateProcessResult
March 15, 2004Featured article candidatePromoted
July 25, 2006Featured article reviewDemoted
September 9, 2006Good article nomineeNot listed
Current status: Former featured article

Microsoft moving to Rust

[edit]

@Chumpih: Re "Microsoft aims to move to Rust by 2030" (diff): I believe that has been debunked. For example, see infoworld.com. Johnuniq (talk) 08:38, 27 December 2025 (UTC)Reply

Thanks for that. I also see similar pieces like this one . Do please improve the text! Chumpih t 09:06, 27 December 2025 (UTC)Reply
Actually, removal is likely appropriate. I'll do as such. Chumpih t 09:11, 27 December 2025 (UTC)Reply

Name origin dispute

[edit]

Talk:B (programming language)#Contradictory Origin of B

There is some dispute on the origin of the name "B", which also pertains to the B section of this article. It was suggested to bring it up on this talk page for more input.

As is, the paragraph in the lead of the B article needs rewriting, but I don't know what can be reliably sourced and if this starts to constitute original research. | Randomno | talk | 15:36, 16 January 2026 (UTC)Reply

Relevance of linux using rust as a mitigation for C issues

[edit]

> Since the early 2020s the Linux kernel has sections written in Rust, a language which has specific measures to improve safety.[72]

I would like someone to explain why this is relevant. This is basically "dont use C", so how is it a valid "mitigation"? ~2026-61487-7 (talk) 15:16, 28 January 2026 (UTC)Reply

C's problems with memory safety are apparently behind a lot of cybersecurity threats.1 The move to Rust in the linux kernel is to avoid those problems. 2 This seems like a significant and relevant change. Chumpih t 21:24, 28 January 2026 (UTC)Reply
I agree that using another Language, like Rust, fixes problems like C. But I also think that the Paragraph, as it is now, feels out of place. I think it would be better to explicitly state that a possible mitigation for C's issues is to not use C, and cite examples of projects miving to Rust, like the Linux kernel. ~2026-61487-7 (talk) 13:23, 31 January 2026 (UTC)Reply
And if we're mentioning Rust in this context then it would make even more sense to say that a common solution is to move to C++, like GCC, GDB, and a bunch of other projects did. ~2026-10569-60 (talk) 20:47, 16 February 2026 (UTC)Reply

month[11] vs. month[12]

[edit]

An edit on 14 November 2011 introduced month[12]. On 23 November 2011 that was changed to month[11]. The same disagreement occurred recently. The 12 proponents are talking about declaring the array while the 11 people are talking about indexing the last element. Perhaps it should read int month[12] to make the declaration clearer? Or replace it with v[3] to illustrate indexing and avoid the issue? Johnuniq (talk) 01:06, 29 October 2026 (UTC)Reply

If I were to choose between declaration or indexing for the example, I would use declaration since I think it's a better encapsulator of array usage, especially in such a brief description.
However, using v[] instead of month[] might be better in general. As far as I can tell, using month isn't part of any overarching example that also uses day, year, etc. so I don't see a strong need to keep that particular example. GoobRobinson (talk) 01:19, 29 October 2026 (UTC)Reply
per suggestions above, v[] makes sense. Or vals[47] ? A definition like float vals[47]; would work, too. Chumpih t 08:11, 29 October 2026 (UTC)Reply
I changed it to v[3] just to illustrate the syntax. Trying to explain what a declaration is at that early stage of the article would not be helpful. Johnuniq (talk) 08:36, 29 October 2026 (UTC)Reply