From: Junio C Hamano <gitster@pobox.com>
To: Phillip Wood <phillip.wood123@gmail.com>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
Neeraj Singh <nksingh85@gmail.com>,
Johannes Schindelin via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org
Subject: Re: [PATCH] git-compat-util(msvc): C11 does not imply support for zero-sized arrays
Date: Thu, 09 Dec 2021 13:18:27 -0800 [thread overview]
Message-ID: <xmqqfsr1pjdo.fsf@gitster.g> (raw)
In-Reply-To: <f245f2b7-ca00-5497-3d1d-658c4c0fbcb6@gmail.com> (Phillip Wood's message of "Thu, 9 Dec 2021 11:00:55 +0000")
Phillip Wood <phillip.wood123@gmail.com> writes:
>> the end of a struct isn't triggering a compile error. But having a field
>> _after_ that empty flex array _does_ trigger a compile error:
>> struct MyStruct {
>> int x;
>> int flexA[];
>> char string[256];
>> };
>> Note the added `string` field.
Ick.
If we use the "safer but a bit wasteful" alternative in such a case,
it will become just wrong. We'll have a single-member array there,
and extra allocation for an instance of MyStruct will only lengthen
the .string member, without allowing the .flexA member to have more
elements.
> Having a field after the flex array is a violation of the C
> standard. Section 6.7.2.1:
> ... the last member of a structure with more than one named member
> may have incomplete array type, such a structure (and any union
> containing, possibly recursively, a member that is such a structure)
> shall not be a member of a structure or an element of an array.
>
> Note that the wording also forbids
>
> struct A {
> int x;
> char flex[];
> };
>
> struct B {
> struct A a; /* This is forbidden */
> };
>
> There was a proposal a few years ago to relax that restriction [1] but
> it does not seem to be in the latest draft standard.
>
> None of this helps fix the problem, but it does explain why MSVC complains.
Thanks.
In short, the code is wrong, and the compiler is complaining to
avoid us using a wrong code. If the same code is given to other
compilers that support ANCI C style flexible array member, we are
likely to see the same error.
Which makes the whole thing (including my "let's make the
conditionals to set up FLEX_ARRAY for various compilers easier to
read") much less urgent.
Thanks for a well-written summary.
next prev parent reply other threads:[~2021-12-09 21:18 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-06 20:48 [PATCH] git-compat-util(msvc): C11 does not imply support for zero-sized arrays Johannes Schindelin via GitGitGadget
2021-12-06 21:48 ` Junio C Hamano
2021-12-06 22:25 ` Neeraj Singh
2021-12-07 21:33 ` Johannes Schindelin
2021-12-07 22:22 ` Neeraj Singh
2021-12-07 22:59 ` rsbecker
2021-12-09 11:00 ` Phillip Wood
2021-12-09 21:18 ` Junio C Hamano [this message]
2021-12-09 1:39 ` Junio C Hamano
2021-12-09 1:49 ` Neeraj Singh
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=xmqqfsr1pjdo.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=nksingh85@gmail.com \
--cc=phillip.wood123@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.