Jump to content

Talk:C (programming language)

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
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

RFC on Placement of opening bracket

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


I am requesting comments to move the opening bracket ('{') from a newline to the same line as the signature. My reasoning is to cite this:[1] This is cited in the page "Hello, World!" program which provides a Hello, world program in C cited from the K&R book. If approved I will apply this change to both the original "Hello, world" program and the more modern version.

Please provide comments and thoughts. 24.50.56.74 (talk) 18:34, 20 October 2025 (UTC) 24.50.56.74 (talk) 18:34, 20 October 2025 (UTC)[reply]

References

  1. ^ Kernighan, Brian (1974). "Programming in C: A Tutorial" (PDF). Bell Labs. Archived (PDF) from the original on 22 March 2022. Retrieved 9 January 2019.
I would not recommend a change. I have programmed in C for a very long time, and opening braces were always put at the same position as the closing braces. In all C (and C++ books later on) this is the way programs are represented. Don't change it because in one publication it is different. Take a look at "The C programming language" of K&R and you will see what I mean. — DandoriD (talk) 10:24, 21 October 2025 (UTC)[reply]
Please see WP:RFCBEFORE. Where is the deadlocked dispute that has made a full-blown thirty-day formal RfC necessary? Aside from that, a C compiler simply does not care. Like most ALGOL-derived programming languages, you can write it all on one line, or each token on a separate line; you can have any number of leading spaces, tabs, both or neither; and it makes not one scrap of a difference. The only time that is does matter to the compiler is when you use preprocessor directives like #include <stdio.h> which must be followed by a newline. In short, this is valid:
#include <stdio.h>
int main(void){printf("hello, world\n");}
and so is this:
#include <stdio.h>
int
main
(
void
)
{
printf
(
"hello, world\n"
)
;
}
When you write your own C programs, you can lay it out however you like. If you are at a university, they may teach you one way; another university might teach a different way. Neither of them is wrong. The only time that it "matters" is when you work for a company that has house style rules and you're sharing code with a programming team. --Redrose64 🌹 (talk) 20:30, 21 October 2025 (UTC)[reply]
Like Dandorid, I would not recommend a change either. For the function body, I've almost always seen the opening and closing braces on their own lines in actual C sources. Since this style is very common, we should follow it (at least, for existing examples in WP, we should not change it to some other, rarely used style). The K&R book is very old, and practice has evolved to ease readability. — Vincent Lefèvre (talk) 23:41, 21 October 2025 (UTC)[reply]
I don't have a strong opinion, but this image supports the stance from @Vincent Lefèvre and @Dandorid.
"Hello, World!" program handwritten in the C language and signed by Brian Kernighan (1978)
And per @Redrose64's comments, the RfC does indeed seem excessive. Chumpih t 06:41, 22 October 2025 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

@Dandorid, I also once believed that there was a "correct" way to place braces that was also "consistent". You may be surprised to learn how many different ways of placing braces that each have their supporters -- so many that there are plenty of reliable sources for each one and several Wikipedia articles discussing the controversy: Indentation style, Programming style, Coding conventions, Pretty-printing, GNU coding standards, indent (Unix), etc. --DavidCary (talk) 22:21, 6 November 2025 (UTC)[reply]

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]