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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.