Talk:getaddrinfo

Code examples

The code for the getaddrinfo client is aweful! —The preceding unsigned comment was added by 207.47.10.130 (talk • contribs).

I've removed the long code examples per WP:NOT. -- intgr 09:46, 4 April 2007 (UTC)

Expansion and new code

All previous code was bad for encyclopedic use. It was wrong too, since the hostname buffer was already at maximum allowed size and reallocs were unnecessary. NI_MAXHOST isn't mentioned in RFCs anymore because it's not a restriction in the addrinfo API, but originates from the name server implementation, <arpa/nameser.h>. Expanded the article with the sister function getnameinfo and freeaddrinfo and added prototype definitions. Sample code now shows the power of returning multiple results, however, stays away from detailed requests via hints and flags. A redirect from nonexistent getnameinfo to this article was also created. Kbrose (talk) 20:19, 14 December 2008 (UTC)

Long example removed

[Section moved from User talk:intgr]

Hi,

I've been attempting to add sample code to getaddrinfo because the code there is useless. My edit has been reverted twice. The revert comments go something along the lines of "Wikipedia is an encyclopedia, not a code repository/programming contest."

I repeat, THE EXAMPLE CODE ON THE PAGE IS USELESS. I'm trying to improve the content of the page by adding a code sample which shows the proper/intended usage of getaddrinfo.

Since you were the last to revert the page, would you be so kind as to let me know what I can do to insure the new code sample sticks?

Thanks, Reubenhwk (talk) 20:37, 8 December 2010 (UTC)

I haven't looked into the current code in detail, but seems to demonstrate the API — that's all it's supposed to do. It compiles and runs on my computer. It's not supposed to be a useful program for any practical purpose. If you have good reasons, you can delete it as well, I won't object to that.

As for the code that you're trying to add, sorry. Even if it's better or more correct, it is too long and complicated. You can add an external link and host the code elsewhere, but that monster just doesn't belong on Wikipedia. -- intgr [talk] 21:24, 8 December 2010 (UTC)

The bar is set too low: "seems to demonstrate the API — that's all it's supposed to do." Good job. — Preceding unsigned comment added by Reubenhwk (talk • contribs) 23:11, 8 December 2010 (UTC)

Changes to usage

@Taylor Riastradh Campbell, you claimed that you "fixed bugs", however this was merely a justification to revert the edits made to this page.

• Italicising variables/arguments does not make sense here. Those are parameters of a function, and thus are identifiers in code. They should remain monospaced.
• There was no bug in the code either. In fact, the code you reverted it back to is even more outdated, and makes several poor design choices; namely declaring multiple symbols per line, declaring uninitialised variables only to assign them later, and then changing the while loop which is clearer in intent to a for loop.

~2025-36699-87 (talk) 21:15, 15 December 2025 (UTC)

Italicising variables/arguments does not make sense here. Those are parameters of a function, and thus are identifiers in code. They should remain monospaced.

Common style is to use italic or slanted face for variables/parameters and upright monospace face for literal code displays. See, for example, GNU Texinfo used to prepare the glibc manual, or the OpenBSD man page in HTML, or the Solaris man page typeset in PDF, or the POSIX.1-2024 getaddrinfo() specification, or the X/Open XNS Issue 4 typeset PDF (some of these references are older; some of them are from the last year). It may not be your preferred style but it is in widespread use, including in the specific citations that support this article's content. (Those citations also, incidentally, uniformly write struct addrinfo **, not struct addrinfo**.)

There was no bug in the code either.

The code would not even compile before I fixed it.

If you, ~2025-36699-87, are the same editor who reverted my change under a different temporary account, please consider alternative hypotheses before you accuse other editors of “deceit”. Taylor Riastradh Campbell (talk) 02:39, 16 December 2025 (UTC)

If you are so upset about me calling you deceptive, then don't bring up unrelated incidents involving me to discredit my actions on other pages. Things like the Java Platform Module System copyright infringement have zero relation to this dispute, and neither do any of the ill-informed accusations of edit warring that existed in these pages. You evidently made zero effort to read my talk page, and just accepted that me being accused of edit warring suited your narrative, while it was the case that most of these were either predicated on misunderstandings or the like. ~2025-36699-87 (talk) 04:57, 16 December 2025 (UTC)

@Taylor Riastradh Campbell I don't know what you possibly mean by your frankly untruthful claim that I am "violating style changes" in any of my edits. This is blatantly untrue. I preserved the alignment of pointers on the page, and all of the code I demonstrated does indeed compile. I don't know what you are suggesting, but you haven't actually demonstrated any valid reason to undo my edits. ~2025-42678-33 (talk) 10:19, 26 December 2025 (UTC)

Coding style is not just about alignment of pointers. And if the existing code still compiles and works without any issue, it should not be changed, unless there is a serious issue with its style or it is very uncommon. — Vincent Lefèvre (talk) 20:59, 26 December 2025 (UTC)

It is uncommon, and this isn't 1980. There is literally no reason to declare all variables at the top of the function before use, and especially no reason to declare int error; when error is immediately assigned on the line after. Declaring a for loop variable outside of the for loop and then iterating over it is far less clear about the intent than simply using a while loop. Furthermore the comment about a line longer than 80 characters, which will not fit in some terminals does not apply. This is not a terminal, this is a code block, and the line contents extend onto another line on the browser without starting another line in the code itself. And if this is such an issue, that does not justify removing other things. ~2025-42678-33 (talk) 22:50, 26 December 2025 (UTC)

I don't see any issue in declaring the variables at the top of a function or logical block. That's an easier way to find their type than having to look at the whole function body if it is rather long. Another advantage is that the type consistency can be more visible.

The for loop can be regarded as being clearer than a while loop since it still has the form of a loop over a variable. FYI, this is apparently an example copied from glibc's nss/tst-getaddrinfo.c, which has for (ai = aitop; ai != NULL; ai = ai->ai_next) (so, identical except for a variable name).

Concerning the maximum number of characters per line, this is a general rule for readability, traditionally in 80-column text terminals, and also on mobile phones nowadays (though 80 may even be considered too much). For instance, the GNU Coding Standards have the following recommendation:

Please keep the length of source lines to 79 characters or less, for maximum readability in the widest range of environments.

In short, there are no real issues with the existing code. At most, this is a matter of preference.

— Vincent Lefèvre (talk) 02:24, 27 December 2025 (UTC)

I don't see any issue in declaring the variables at the top of a function or logical block. That's an easier way to find their type than having to look at the whole function body if it is rather long. The variables used inside the function are not the important part, the logic is. The traditional reason why this was done, especially prior to C99, was because of compiler limitations where knowing size of variables was necessary for efficient allocation. This does not apply anymore today, and there is no reason to continue to pretend that this limitation still exists. Another advantage is that the type consistency can be more visible. I don't know what you mean by this, but if anything it's simpler to only declare variables as needed. Declaring variables at the top does not make it obvious that they are going to be assigned a value right away, and declaring the variable right at the point of usage provides better context and is clearer why that variable is used, rather than simply declaring it at the top. The for loop can be regarded as being clearer than a while loop since it still has the form of a loop over a variable. This is again ancient code where even the iterating variable of a for loop is declared at the top of the function (see for (index = 0; index < sizeof (family) / sizeof (family[0]); ++index)), which hasn't been necessary since C99 (where variables could not be declared inside the loop). It is more idiomatic to use a while loop to represent checking a condition while iterating. You will also notice that the code does things that are pointless in modern C - there is no need to use memset to initialise a struct, and since C99 structs can be directly initialised at declaration. Please keep the length of source lines to 79 characters or less, for maximum readability in the widest range of environments. I frankly don't really have any problem with breaking it into two lines, but it certainly does look awkward. Examine:

error = getnameinfo(ai->ai_addr, ai->ai_addrlen,
            hostname, sizeof(hostname), NULL, 0, 0);

The function name is declared on one line and then another half of the parameters appear on the next. At least having the parameters in a cohesive area has a more natural flow. I personally prefer breaking it into more lines by having parameters on separate lines from the function name, as the arguments are more clear and visible and the cohesiveness and structure flow better. This also makes more sense in practice to prevent misaligning arguments or running into long lines in the event of needing to add/remove/reorder parameters.

error = getnameinfo(
    ai->ai_addr, ai->ai_addrlen, hostname,
    sizeof(hostname), NULL, 0, 0
);

~2025-42678-33 (talk) 03:44, 27 December 2025 (UTC)

@Vincent Lefèvre I would like to hear a response to this, as I don't think any of my responses are unreasonable for the scope of this article. ~2025-42678-33 (talk) 17:52, 28 December 2025 (UTC)

The new versions of the C standard gives more latitude about how to write code, but there is no obligation to use new features, even for new code. This is all about personal choice, but also the context.

The for loop has advantages. For instance, it allows one to use the continue statement more cleanly in such a case, with less risk of errors and better maintainability. And as all what is needed about the iteration is put before the main body, one can write macros based on it, such as all these list_for_each[...] macros in the Linux kernel source code (list.h) for its linked lists.

In your code, you use the type name twice in the source. If one needs to change the type, one needs to remember to update it at the other place. That said, I suppose that this can now be avoided thanks to typeof.

Concerning the split on 2 lines, it is very common to have additional arguments on the next line. One normally prefers to align the arguments on the same column, AFAIK. However, note that the unaligned split in the example is very similar to what C23 does in 6.10.4.2 or 7.17.8.2, for instance. What you are suggesting (on 4 lines) seems uncommon; which software chooses such a style?

— Vincent Lefèvre (talk) 22:56, 28 December 2025 (UTC)

I will acknowledge that I have made a mistake, that the while loop is indeed unnecessary. However, there is no reason to declare the iterated struct addrinfo *ai outside the for loop as it is never used outside of it (see previous explanation about why this is unnecessary). Furthermore, int error; is immediately assigned in the line after it is declared. This is pointless, I have changed it so that it is assigned immediately at site of declaration. ~2025-42678-33 (talk) 01:31, 29 December 2025 (UTC)

@Taylor Riastradh Campbell, the only one forcing a personal style on Wikipedia is you, by failing to give any tangible benefit for continuing to use the older sample. I have already given two clear benefits for my changes - preventing struct addrinfo *ai from having greater scope than it needs, and leaving the variable error uninitialised. There is no benefit for continuing to leave it as it is. ~2026-58554-3 (talk) 20:25, 31 January 2026 (UTC)

@Taylor Riastradh Campbell, the only one forcing a personal style on Wikipedia is you

Interesting, were these calls for style changes not made by you? Did someone other than you repeatedly apply them over the objections of other editors who took the time to engage?

https://en.wikipedia.org/w/index.php?title=Talk:Pointer_(computer_programming)&oldid=1332962673#RFC_on_Pointer_alignment_in_examples

https://en.wikipedia.org/w/index.php?title=Talk:Union_type&oldid=1335896862#Left/right_alignment_of_pointers

https://en.wikipedia.org/w/index.php?title=Talk:C_data_types&oldid=1332962678#RFC_on_Pointer_alignment

https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:WikiProject_Computer_science&oldid=1331527988#C/C++_pointer_asterisk_and_null_checks

I certainly don't recall making those calls, and the plain consensus of these discussions is to ask whatever anonymous editor keeps pushing their style changes to cut it out and stop wasting everyone's time. Taylor Riastradh Campbell (talk) 20:58, 31 January 2026 (UTC)

Yes, continue dodging the question and instead whine about stale/inactive discussions that happened months ago, I'm sure that will prove to everyone why all the variables have to be declared at the beginning of the function's body. ~2026-58554-3 (talk) 21:08, 31 January 2026 (UTC)

There is nothing wrong with putting a declaration above an assignment:

int error;
​
error = foo();
if (error)
        goto out;
​
error = bar();
if (error)
        goto out;
​
error = baz();
if (error)
        goto out;

This makes it visually more consistent and easier to edit—and easier to review edits and avoid merge conflicts—in case the foo/bar/baz ordering needs to change, or the foo() call needs to be deleted or another call inserted before it.

There is also nothing wrong with expanding the scope of a variable to declutter the syntax of a long line, and leave space for other logic:

for (struct ACPI_EINJ_ENTRY *entry = block; entry < end; entry = find_next(entry)) {
        ...
}

versus

struct ACPI_EINJ_ENTRY *entry;
unsigned i;
​
for (i = 0, entry = block; entry < end; i++, entry = find_next(entry)) {
        ...
}

You seem to have a pattern of demanding style changes to suit your preferences, and then applying the changes over objections and flouting the consensus, which sounds a lot like WP:ICANTHEARYOU in, for example, your exchange with MrOllie at https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:WikiProject_Computer_science&oldid=1331527988#C/C++_pointer_asterisk_and_null_checks. Objections don't have to be renewed every month, as you were already told just a few months ago. I am reverting your style-only changes not because my style is better but because your changes repeatedly demonstrate contempt of the consensus of fellow editors. Taylor Riastradh Campbell (talk) 21:46, 31 January 2026 (UTC)

Please learn to let bygones be bygones and quit rehashing old arguments. I'm afraid you're just beating a WP:DEADHORSE.

but because your changes repeatedly demonstrate contempt of the consensus of fellow editors.

Thanks for admitting that you're reverting "style-only" (not style-only as I have explained already) edits not because of utilitarian reasons, but out of spite. WP:POINT much. ~2026-58554-3 (talk) 21:54, 31 January 2026 (UTC)

@Taylor Riastradh Campbell I don't know who you think you are, but Restore working example code from disruption by an anonymous editor who has apparently been repeatedly flouting community consensus to impose personal style preferences across Wikipedia for months. is not a substantive justification for what's clearly your own imposition of style, by calling any edits to the code someone else's personal style preferences. I've explained countless times why these changes were made, and you continue to fall back to an erroneous claim that my edits are style-only when they clearly are not. At this point it's worth questioning whether you are just WP:HOUNDING out of some personal vendetta when you attempt to suppress edits based on the justification that they came from a certain person, and making no attempt to evaluate the merits of the edits themselves. Falling back to previous, long-finished discussions is WP:DEADHORSEing, and your refusal to engage in the talk page while then throwing a tantrum in the edit summary about how someone is "flouting community consensus" is not substantive in any capacity. (Update: I'm going to call WP:3O for this dispute seeing as there are only two editors actively involved.) ~2026-58554-3 (talk) 15:24, 1 February 2026 (UTC)

 RESPONSE TO THIRD OPINION REQUEST

---

@~2026-58554-3 and @Taylor Riastradh Campbell; This 3O request has sat for awhile as it appears too technical for the average editor. Can you both please break-down your arguments and your primary contentions into something less-technical? At that point, I will do my best to render a policy-based decision. Cheers — MWFwiki (talk) 00:12, 9 February 2026 (UTC)

Essentially, I've made a bunch of changes to the code which include:

• Only declaring variables at the site of usage, rather than at the top. Historically, declaring everything at the top was preferred as computers had far more limited memory resources, and this allowed it to be easier to see how much memory would be used in a stack frame during a function call. But there is no longer need for this - it is better to limit the scope of variables to be only where they are needed to function.
• Assign variables when they are declared, rather than declare them and leave them uninitialized. Uninitialized variables are often a source of errors in code. Furthermore, use different variables for different errors rather than reuse the same variable. This is more consistent with easy-to-follow logic.
• Use clearer logic for error checking (by checking return values of a function call), and making the error messages more clear.
• Remove highlighted lines, because what they apparently intend to serve is already accomplished by the above paragraph.

A lot of the complaints made against my changes, seem to boil down to accusations of me "imposing my personal style" across Wikipedia, which I think is frankly untrue. The only grounds for this accusation were that I had campaigned to use certain alignments for where to place an asterisk; I later dropped this effort and haven't raised it in my current changes to this page. I don't think any of the changes I made here were "style-changes" - they served clear utilitarian purposes towards actually making the code clearer and moved away from obscurer or older practices. ~2026-98848-3 (talk) 19:01, 13 February 2026 (UTC)

I completely disagree with the changes done by ~2026-98848-3 (or one of its multiple temporary accounts or IPs). BTW, the new code does not even compile, and this user has already introduced errors in the past.

The original code was correct, much shorter and its style reflected the actual usage. I do not see a need for a change of the original code (except that highlighting could be removed as it seemed useless).

To quickly answer the above points:

• Declaring variables at the top is still used in practice and has its advantages (e.g. the types are grouped at one place, and this may make the code more readable).
• An uninitialized variable (before its use) is still better than giving an arbitrary value (together with the help by compilers' code analysis to warn about the use of uninitialized variables); an arbitrary value could mean that it will have to be overwritten by the wanted value, and if not done, the compiler will not be able to warn.
• Error checking in the original code was correct, AFAIK.
• Highlighting could be removed from the original code.

And in short, I mostly agree with Taylor Riastradh Campbell's arguments.

Note: I haven't answered more often due to a lack of time. — Vincent Lefèvre (talk) 16:17, 17 February 2026 (UTC)

Are we all just incapable of fixing typos or something? A typo doesn't discredit the edits, and we are all adults here, we can address the edits fairly without grasping for straws by complaining that the code doesn't compile, as if the existing code is deeply fundamentally flawed rather than just in need of a few fixes. How about we refrain from comments like user has already introduced errors in the past as these errors were illogical or nonsensical code, and were not simply typos.

Declaring variables at the top is still used in practice and has its advantages (e.g. the types are grouped at one place, and this may make the code more readable).

This was only a rule in K&R C, in other words very old C (Chapter 1.2 of K&R: "In C, all variables must be declared before they are used, usually at the beginning of a function, before any executable statements.", and this was forced because of technical limitations). Modern C (at least since C99) does not have this restriction anymore, and continuing to force it is not only arbitrary, but you are also forcing variables to have greater scope than necessary, such as loop variables.

An uninitialized variable (before its use) is still better than giving an arbitrary value

The changes eliminated uninitialized variables without introducing any arbitrary values at all so this isn't relevant.

Error checking in the original code was correct, AFAIK.

As I have explained before, I changed the error messages to be clearer and descriptive and introduced separable variables for error codes. gai_rc is for the return code to getaddrinfo() while gni_rc is for the return code to getnameinfo(). This is for making debugging easier, preventing confusion about what the variable contains, and avoiding using the wrong value accidentally. We aren't so constrained on memory that we can't afford a different variable, anyway.

~2026-11301-79 (talk) 04:43, 20 February 2026 (UTC)

Thanks for volunteering to mediate, and apologies for how frivolous this may seem.

The context is that what appears to be one anonymous editor cycling through temporary accounts over the course of several months (one of whom acknowledged being the same person as the others to date) has decided to impose personal coding style preferences, not supported by any Wikipedia style guide, on programming articles across Wikipedia, despite being repeatedly told not to do this.

For a non-technical audience, it's like an editor has:

1. come up with their own set of English writing style rules not in WP:MOS (e.g., avoiding split infinitives, or refusing to start otherwise grammatically correct sentences with "because"), and
2. gone through various articles to change the existing style, against MOS:VAR, and
3. kept at it after being told over and over again to stop,

and now they're casting a wider net for any editors who haven't yet objected to provide input.

In the course of doing this, they have also introduced errors, and reverted my correction of errors while accusing me of "blatantly deceitful justification"—not just here but also in other articles like this fix in C data types (fix reverted).

For the specific style this editor objects to, here is an example of real-world usage (which I was not involved in writing, though I have met the original author), in modern C code written in the last decade, both declaring the variable error up front and reusing it to hold the error indicators of multiple subroutine calls:

void
init_gdb(struct vmctx *_ctx)
{
	int error, flags, optval, s;
...
	error = pthread_mutex_init(&gdb_lock, NULL);
	if (error != 0)
		errc(1, error, "gdb mutex init");
	error = pthread_cond_init(&idle_vcpus, NULL);
	if (error != 0)
		errc(1, error, "gdb cv init");
...
	error = getaddrinfo(saddr, sport, &hints, &gdbaddr);
	if (error != 0)
		errx(1, "gdb address resolution: %s", gai_strerror(error));

The style of reusing the same variable for an error indicator, and immediately branching to test and report the error, is widespread even beyond C; for example, this Go tutorial on error handling does the same thing:

    if err := datastore.Get(c, key, record); err != nil {
        return &appError{err, "Record not found", 404}
    }
    if err := viewTemplate.Execute(w, record); err != nil {
        return &appError{err, "Can't display record", 500}
    }

It is so embedded in the culture that I expect—as a software engineer with many years of professional experience—that a change to use two separate variables for getaddrinfo and getnameinfo error codes stands a decent chance of being rejected by code reviewers experienced in C (or Go) even though it's only a style choice, unless there is something particularly unusual going on in the code to require use of both variables for different purposes at the same time, which is not the case here.

(Personally, in the FreeBSD bhyve code I quoted above, I would actually use two variables, one for the pthread error numbers and one for the getaddrinfo error number, because pthread error numbers and getaddrinfo/getnameinfo error numbers are interpreted differently—but this isn't about my personal preferences; it's about actual usage.) Taylor Riastradh Campbell (talk) 18:23, 28 February 2026 (UTC)

one anonymous editor cycling through temporary accounts over the course of several months

Since you're apparently unaware, temporary accounts cease to persist after a period of time. I don't understand why you think trying to list every single known account of mine is some kind of Sherlockian discovery or is some smoking gun, such that you would need to bring emphasis to this every time an argument involving me happens. My only guess is that you think this is a means to incriminate me for sockpuppetry, which might apply if I attempted to use multiple temporary accounts simultaneously or if the accounts were registered, but unfortunately for you that's not the case. At no point have I claimed to be a distinct person, and I'm not obligated to list every previous temporary account I've edited under, nor am I obligated to register an account of my own either. But, to entertain your WP:HOUNDING:

repeatedly

You're alleging something that isn't true, and have offered no explanation to back up your wild allegations. I'm not pushing site-wide standardisation, and the discussion you cited was dropped ages ago. Do better.

told

This is a comment in the same discussion, not a different situation. Do better.

not

This is a comment left in a discussion I had, regarding a different set of articles, back when I wanted to push for left-aligning pointer asterisks. I haven't pushed for this in more than half a month, you're reaching for straws and you aren't impressing anyone.

to

This is someone, adding literally nothing to the conversation to an RfC I proposed, once again for a completely separate issue. If you think you're going to prove your point by overwhelming the WP:3O mediator with these frankly worthless examples, I'm afraid your mistaken.

do

This is a far more neutral statement than anything you tried to portray it as, nice try.

this

Ditto.

For a non-technical audience, it's like an editor has: come up with their own set of English writing style rules not in WP:MOS (e.g., avoiding split infinitives, or refusing to start otherwise grammatically correct sentences with "because"), and gone through various articles to change the existing style, against MOS:VAR, and kept at it after being told over and over again to stop,

These comments about the English language are completely incomparable to programming, because programming evolves much more rapidly than the English language, or any language for that matter. I suppose if the English language were also constrained by a speaker's resources in such a way that these resources changed (I guess through evolution) and were it the case that the linguistic development space was radically changing every few years, this argument might apply.

In the course of doing this, they have also introduced errors, and reverted my correction of errors while accusing me of "blatantly deceitful justification"—not just here but also in other articles like this fix in C data types (fix reverted).

I think this fixation on the few programming errors that were introduced (and fixed, by myself) is what's particularly frivolous, and even petty. It's the equivalent of trying to dismiss someone's argument based on using the wrong "there/their/they're" in an edit - just because it is syntactically incorrect English doesn't invalidate the merits of the edits entirely. This sort of fixation on the few programming errors that were introduced over the course of my edits is just blatant grasping for straws. These errors were not some deep fundamental error such that the code couldn't be recovered into a state that is usable - it's as minuscule as an incorrect spelling or improperly used function word, in any other edit.

At this point, it's increasingly difficult to be able to assume good faith about User:Taylor Riastradh Campbell, because they are continuing to misrepresent the situation to an admittedly less technically-versed 3O mediator (i.e. claiming that this is comparable to someone inventing their own rules for writing the English language), while refusing to address my responses to accusations, while misrepresenting my actions as well to give the impression that I am part of some malicious group trying to push my own conventions. But seeing as this user is likewise immediately assuming bad faith about all of my edits (trying to imply my use of multiple temporary accounts over the course of months is some attempt to deceive rather than just a fact that Wikipedia offers temporary accounts that are flushed after a period of time), I don't think I'm obliged to reciprocate anything.

For the specific style this editor objects to, here is an example of real-world usage (which I was not involved in writing, though I have met the original author), in modern C code written in the last decade, both declaring the variable error up front and reusing it to hold the error indicators of multiple subroutine calls:

So what? Anyone can find "real examples" of code doing particularly egregious things. Just because this appeared in a snippet of FreeBSD code doesn't mean this is exemplar, stellar code, they also used /* multi-line comments */ on lines spanning only one line, despite there being literally no need for this, other than historic momentum to preserve this antiquated way of programming in older code bases (such as the Linux kernel and FreeBSD), whose style guides were shaped by the limitations of older C standards. The fact of the matter is, is any query online about whether variables should be declared as immediately or as late as possible, will overwhelmingly all recommend the latter, just as it is almost unanimous that reusing variables as much as possible does not improve performance today.

I would also like to remind the 3O arbitrator that the following was said by User:Taylor Riastradh Campbell: I am reverting your style-only changes not because my style is better but because your changes repeatedly demonstrate contempt of the consensus of fellow editors. They are, by their own admission, trying to make a WP:POINT, by admitting to reverting edits not because it decreases the quality of the article, but because they deem it to be a style change (which I have explained time and time again that it is not a style change).

Meanwhile, your Go example doesn't apply to C, because error handling is built into the language design of Go (i.e. functions often return (value, error) and is a language-enforced pattern, whereas in C functions often return only int to indicate status code or set the errno global variable. Broadly speaking, the claim that it is widespread beyond C, isn't true, because most languages have better error handling facilities than those offered in C. C++, Python, C#, and Java offer exceptions. C++ and Rust also offer a Result<T, E>-like type, and the closest comparable example I could find is the following:

use std::fs::File;
use std::io::{self, Read};

fn read_username_from_file() -> Result<String, io::Error> {
    let username_file_result = File::open("hello.txt");

    let mut username_file = match username_file_result {
        Ok(file) => file,
        Err(e) => return Err(e),
    };

    let mut username = String::new();

    match username_file.read_to_string(&mut username) {
        Ok(_) => Ok(username),
        Err(e) => Err(e),
    }
}

e is "reused" as a name, but is a distinct error variable with its own scope.

Now, you want to talk about actual usage in code? There are plenty of examples of real code that do not follow this rule of declaring all variables up-front. Raylib, an established C library, doesn't do this, and follows the style that I described here:

bool SaveFileData(const char *fileName, void *data, int dataSize)
{
    bool success = false;

    if (fileName != NULL)
    {
        if (saveFileData) return saveFileData(fileName, data, dataSize);

        FILE *file = fopen(fileName, "wb");

        if (file != NULL)
        {
            // WARNING: fwrite() returns a size_t value, usually 'unsigned int' (32bit compilation) and 'unsigned long long' (64bit compilation)
            // and expects a size_t input value but as dataSize is limited to INT_MAX (2147483647 bytes), there shouldn't be a problem
            int count = (int)fwrite(data, sizeof(unsigned char), dataSize, file);

            if (count == 0) TRACELOG(LOG_WARNING, "FILEIO: [%s] Failed to write file", fileName);
            else if (count != dataSize) TRACELOG(LOG_WARNING, "FILEIO: [%s] File partially written", fileName);
            else TRACELOG(LOG_INFO, "FILEIO: [%s] File saved successfully", fileName);

            int result = fclose(file);
            if (result == 0) success = true;
        }
        else TRACELOG(LOG_WARNING, "FILEIO: [%s] Failed to open file", fileName);
    }
    else TRACELOG(LOG_WARNING, "FILEIO: File name provided is not valid");

    return success;
}

But, frankly, if this is such a contentious issue, I think it might even be worth considering just eliminating the example section altogether.

~2026-13351-40 (talk) 03:58, 2 March 2026 (UTC)