From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI,
	RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,
	T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4
Received: (qmail 8238 invoked from network); 22 Mar 2022 16:04:17 -0000
Received: from mother.openwall.net (195.42.179.200)
  by inbox.vuxu.org with ESMTPUTF8; 22 Mar 2022 16:04:17 -0000
Received: (qmail 3551 invoked by uid 550); 22 Mar 2022 16:04:14 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
List-ID: <musl.lists.openwall.com>
Reply-To: musl@lists.openwall.com
Received: (qmail 3510 invoked from network); 22 Mar 2022 16:04:13 -0000
Date: Tue, 22 Mar 2022 12:04:00 -0400
From: Rich Felker <dalias@libc.org>
To: Jeffrey Walton <noloader@gmail.com>
Cc: musl@lists.openwall.com
Message-ID: <20220322160400.GC7074@brightrain.aerifal.cx>
References: <b8869794-0624-6a5f-df15-1840609306a1@loongson.cn>
 <20220322125933.GB7074@brightrain.aerifal.cx>
 <CAH8yC8keqOjUwQnbwrDBuMQOhmuscpJ71j0tw0wNZmkJuXUe1g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAH8yC8keqOjUwQnbwrDBuMQOhmuscpJ71j0tw0wNZmkJuXUe1g@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [musl] add loongarch64 port

On Tue, Mar 22, 2022 at 11:06:41AM -0400, Jeffrey Walton wrote:
> On Tue, Mar 22, 2022 at 8:59 AM Rich Felker <dalias@libc.org> wrote:
> > On Tue, Mar 22, 2022 at 11:52:35AM +0800, 王洪亮 wrote:
> ....
> > > +++ b/arch/loongarch64/bits/signal.h
> > > @@ -0,0 +1,79 @@
> > > +#if defined(_POSIX_SOURCE) || defined(_POSIX_C_SOURCE) \
> > > + || defined(_XOPEN_SOURCE) || defined(_GNU_SOURCE) || defined(_BSD_SOURCE)
> > > +
> > > +#if defined(_XOPEN_SOURCE) || defined(_GNU_SOURCE) || defined(_BSD_SOURCE)
> > > +#define MINSIGSTKSZ 4096
> > > +#define SIGSTKSZ 16384
> > > +#endif
> > > +
> > > +typedef unsigned long greg_t, gregset_t[32];
> > > +
> > > +typedef struct sigcontext {
> > > +     unsigned long pc;
> > > +     gregset_t gregs;
> > > +     unsigned int flags;
> > > +     unsigned long extcontext[0] __attribute__((__aligned__(16)));
> > > +}mcontext_t;
> >
> > [0] is not valid, and having a flexible array member here is possibly
> > not even useful since I don't think it would be valid to access it via
> > uc->uc_mcontext.extcontext[] since the instance of mcontext_t inside
> > the ucontext struct does not have FAM space belonging to it, even if
> > additional space was allocated past the end of the ucontext_t. In
> > other words, I think compilers would be justified in treating attempts
> > to access it this way as UB and optimizing them out.
> 
> I believe zero-length arrays are legal in C99. I'm not sure how well
> it applies here or to Musl on some (older?) platforms.

No, those are flexible array members and are declared with [] not [0].