From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Saksham Mittal <gotlouemail@gmail.com>,
Johannes Altmanninger <aclopte@gmail.com>,
git@vger.kernel.org
Subject: Is 'for (int i = [...]' bad for C STD compliance reasons? (was: [PATCH] MyFirstContribution.txt: fix undeclared variable i in sample code)
Date: Sun, 14 Nov 2021 15:28:35 +0100 [thread overview]
Message-ID: <211114.868rxqu7hr.gmgdl@evledraar.gmail.com> (raw)
In-Reply-To: <xmqq7ddbme7q.fsf@gitster.g>
On Sat, Nov 13 2021, Junio C Hamano wrote:
> Saksham Mittal <gotlouemail@gmail.com> writes:
>
>>> It is declared, there is an "int i;" a few lines up.
>>
>> Oh, man, I never even saw that! The patch is completely unnecessary
>> then. Sorry for that!
>
> No need to say sorry; you'd want to be a bit more careful next time,
> that's all.
>
> Also, our code does not introduce a new variable in the first part
> of "for (;;)" loop control, so even if the original lacked decl for
> "i", the posted patch is not how we write our code for this project.
Just curious: Out of preference, or for compatibility with older C
standards?
I'd think with the things we depend on in C99 it's probable that we
could start using this if standards conformance is the only obstacle.
But I haven't tested, so maybe I'm wrong, I'm just assuming that with
the C99 features we do have a hard dependency on surely anyone
implementing those would have implemented this too.
There's also a stylistic reason to avoid this pattern, i.e. some would
argue that it's better to declare variables up-front, since it tends to
encourage one to keep function definitions smaller (various in-tree
evidence to the contrary, but whatever).
I'd generally agree with that viewpoint & desire, but there's also cases
where being able to declare things in-line helps readability, e.g. when
your function needs two for-loops for some reason, they're set a bit
apart. Then the reader doesn't need to scan for whether an "i" is used
in-between the two.
I was thinking of the below code in bundle.c, I suppose some might find
the post-image less readable, but I remember starting to hunt around for
other out-of-loop uses of "i", which the post-image makes clear could be
avoided as far as variable scoping goes:
diff --git a/bundle.c b/bundle.c
index a0bb687b0f4..94edc186187 100644
--- a/bundle.c
+++ b/bundle.c
@@ -194,14 +194,14 @@ int verify_bundle(struct repository *r,
struct rev_info revs;
const char *argv[] = {NULL, "--all", NULL};
struct commit *commit;
- int i, ret = 0, req_nr;
+ int ret = 0, req_nr;
const char *message = _("Repository lacks these prerequisite commits:");
if (!r || !r->objects || !r->objects->odb)
return error(_("need a repository to verify a bundle"));
repo_init_revisions(r, &revs, NULL);
- for (i = 0; i < p->nr; i++) {
+ for (int i = 0; i < p->nr; i++) {
struct string_list_item *e = p->items + i;
const char *name = e->string;
struct object_id *oid = e->util;
@@ -223,12 +223,11 @@ int verify_bundle(struct repository *r,
if (prepare_revision_walk(&revs))
die(_("revision walk setup failed"));
- i = req_nr;
- while (i && (commit = get_revision(&revs)))
+ for (int i = req_nr; i && (commit = get_revision(&revs));)
if (commit->object.flags & PREREQ_MARK)
i--;
- for (i = 0; i < p->nr; i++) {
+ for (int i = 0; i < p->nr; i++) {
struct string_list_item *e = p->items + i;
const char *name = e->string;
const struct object_id *oid = e->util;
@@ -242,7 +241,7 @@ int verify_bundle(struct repository *r,
}
/* Clean up objects used, as they will be reused. */
- for (i = 0; i < p->nr; i++) {
+ for (int i = 0; i < p->nr; i++) {
struct string_list_item *e = p->items + i;
struct object_id *oid = e->util;
commit = lookup_commit_reference_gently(r, oid, 1);
next prev parent reply other threads:[~2021-11-14 14:39 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-13 12:28 [PATCH] MyFirstContribution.txt: fix undeclared variable i in sample code Saksham Mittal
2021-11-13 13:05 ` Johannes Altmanninger
2021-11-13 13:08 ` Saksham Mittal
2021-11-14 6:41 ` Junio C Hamano
2021-11-14 14:28 ` Ævar Arnfjörð Bjarmason [this message]
2021-11-14 18:03 ` Is 'for (int i = [...]' bad for C STD compliance reasons? Junio C Hamano
2021-11-14 18:25 ` Ævar Arnfjörð Bjarmason
2021-11-14 18:57 ` brian m. carlson
2021-11-14 19:33 ` Carlo Arenas
2021-11-14 19:01 ` Carlo Arenas
2021-11-15 6:27 ` [PATCH] revision: use C99 declaration of variable in for() loop Junio C Hamano
2021-11-15 7:44 ` Martin Ågren
2021-11-16 8:29 ` Junio C Hamano
2021-11-15 22:26 ` brian m. carlson
2021-11-17 11:03 ` Phillip Wood
2021-11-17 12:39 ` Ævar Arnfjörð Bjarmason
2021-11-17 22:30 ` SZEDER Gábor
2021-11-18 7:09 ` Junio C Hamano
2021-12-07 11:10 ` Phillip Wood
2021-12-07 20:37 ` Junio C Hamano
2021-12-08 12:17 ` Removing -Wdeclaration-after-statement (was: [PATCH] revision: use C99 declaration of variable in for() loop) Ævar Arnfjörð Bjarmason
2021-12-08 17:05 ` Removing -Wdeclaration-after-statement Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=211114.868rxqu7hr.gmgdl@evledraar.gmail.com \
--to=avarab@gmail.com \
--cc=aclopte@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=gotlouemail@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).