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, NICE_REPLY_A,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 19854 invoked from network); 24 Mar 2022 03:01:34 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 24 Mar 2022 03:01:34 -0000 Received: (qmail 5627 invoked by uid 550); 24 Mar 2022 03:01:31 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 5587 invoked from network); 24 Mar 2022 03:01:30 -0000 To: musl@lists.openwall.com References: <20220322125933.GB7074@brightrain.aerifal.cx> <20220322160400.GC7074@brightrain.aerifal.cx> From: =?UTF-8?B?546L5rSq5Lqu?= Message-ID: Date: Thu, 24 Mar 2022 11:01:17 +0800 User-Agent: Mozilla/5.0 (X11; Linux mips64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20220322160400.GC7074@brightrain.aerifal.cx> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-CM-TRANSID:AQAAf9AxGsz93jtirusOAA--.15081S3 X-Coremail-Antispam: 1UD129KBjvJXoW7Ww1UGFW5tF13GFW5uw47twb_yoW8CF18pF 18Ca4vkF4jqF47C3sFva4Fvr9xKr95JFyUWF98Ww4jv3sxXF1xWr1jqrWYkryqvrn7Aw4j vw1UtryY9F1Fv37anT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUU9Ib7Iv0xC_Cr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_Cr1j6rxdM28EF7xvwV C2z280aVCY1x0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC 0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr 1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcVAKI48JMxk0xIA0c2IEe2xFo4CEbIxvr21l c2xSY4AK6svPMxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMxCIbckI1I 0E14v26r1Y6r17MI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2IqxVCjr7xvwVAFwI0_JrI_JrWl x4CE17CEb7AF67AKxVWUJVWUXwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r 1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42IY6xAIw20EY4v20xvaj40_Wr1j 6rW3Jr1lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVWUJVW8Jb IYCTnIWIevJa73UjIFyTuYvjxU2_HUDUUUU X-CM-SenderInfo: pzdqwxxrqjzxhdqjqz5rrqw2lrqou0/ Subject: Re: [musl] add loongarch64 port Hi, the zero-length array in sigcontext is used for context extend. this applycation has some advantage: 1.the zero-length array not take up space of struct sigcontext 2.the extended context is continuous with sigcontext. Hongliang Wang 在 2022/3/23 上午12:04, Rich Felker 写道: > On Tue, Mar 22, 2022 at 11:06:41AM -0400, Jeffrey Walton wrote: >> On Tue, Mar 22, 2022 at 8:59 AM Rich Felker 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].