[musl] Question about flexible array

[musl] Question about flexible array

[樊鹏]

[-- Attachment #1: Type: text/plain, Size: 2139 bytes --]

hi,

In arch/loongarch64/bits/signal.h, I got some compiling errors about flexible array:

In file included from /usr/include/signal.h:48,
                 from /usr/include/ucontext.h:9,
                 from /home/alpine/aports/community/onetbb/src/oneTBB-2021.12.0/python/rml/../../src/tbb/co_context.h:52,
                 from /home/alpine/aports/community/onetbb/src/oneTBB-2021.12.0/python/rml/../../src/tbb/scheduler_common.h:27,
                 from /home/alpine/aports/community/onetbb/src/oneTBB-2021.12.0/python/rml/ipc_server.cpp:23:
/usr/include/bits/signal.h:35:23: error: flexible array member 'mcontext_t::__extcontext' not at end of 'struct tbb::detail::r1::coroutine_type'
   35 |         unsigned long __extcontext[] __attribute__((__aligned__(16)));
      |                       ^~~~~~~~~~~~
compilation terminated due to -Wfatal-errors.
ninja: subcommand failed
>>> ERROR: onetbb: build failed


The reason is a difference between gcc and g++:

Flexible array members are not officially part of C++.
Flexible array members were officially standardized in C99.

If *.cpp includes this header file, it may result in an error. I suggest to change it to size-zero array format.

Meanwhile, you can also consider the patch I attached.
Your opinions are welcome.

Thanks.

本邮件及其附件含有龙芯中科的商业秘密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制或散发）本邮件及其附件中的信息。如果您错收本邮件，请您立即电话或邮件通知发件人并删除本邮件。 
This email and its attachments contain confidential information from Loongson Technology , which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it. 

[-- Attachment #2: LoongArch-change-flexible-array-format.diff --]
[-- Type: application/octet-stream, Size: 717 bytes --]

diff --git a/arch/loongarch64/bits/signal.h b/arch/loongarch64/bits/signal.h
index 5a9ed8c9..cefa9a61 100644
--- a/arch/loongarch64/bits/signal.h
+++ b/arch/loongarch64/bits/signal.h
@@ -24,7 +24,7 @@ struct sigcontext {
 	unsigned long sc_pc;
 	unsigned long sc_regs[32];
 	unsigned sc_flags;
-	unsigned long sc_extcontext[] __attribute__((__aligned__(16)));
+	unsigned long sc_extcontext[0] __attribute__((__aligned__(16)));
 };
 #endif
 
@@ -32,7 +32,7 @@ typedef struct {
 	unsigned long __pc;
 	unsigned long __gregs[32];
 	unsigned __flags;
-	unsigned long __extcontext[] __attribute__((__aligned__(16)));
+	unsigned long __extcontext[0] __attribute__((__aligned__(16)));
 } mcontext_t;
 
 struct sigaltstack {

Re: [musl] Question about flexible array

[Thorsten Glaser]

樊鹏 dixit:

>The reason is a difference between gcc and g++:
>
>Flexible array members are not officially part of C++.
>Flexible array members were officially standardized in C99.

>/usr/include/bits/signal.h:35:23: error: flexible array member 'mcontext_t::__extcontext' not at end of 'struct tbb::detail::r1::coroutine_type'

No, that’s not the problem here (the compiler allows that).

The problem is this, in oneTBB itself:

    struct coroutine_type {
        coroutine_type() : my_context(), my_stack(), my_stack_size() {}
        ucontext_t my_context;
        void* my_stack;
        std::size_t my_stack_size;
    };

There’s a double problem here. One is the ordering. Changing to…

    struct coroutine_type {
        coroutine_type() : my_context(), my_stack(), my_stack_size() {}
        void* my_stack;
        std::size_t my_stack_size;
        ucontext_t my_context;
    };

… would fix that, but I *bet* that the surrounding code allocates
its struct coroutine_type by a fixed size and copies my_context
by sizeof(ucontext_t), which necessarily does not include the FAM.

I’m not sure if it is even permissible for ucontext_t to contain
a FAM; perhaps instead you need to figure out the exact or a
maximum size and change the declaration (and the ABI, most likely)
to that?

Otherwise, all that’s left is to forbid userspace the copying of
ucontext_t, which probably won’t fly…

bye,
//mirabilos
-- 
“ah that reminds me, thanks for the stellar entertainment that you and certain
other people provide on the Debian mailing lists │ sole reason I subscribed to
them (I'm not using Debian anywhere) is the entertainment factor │ Debian does
not strike me as a place for good humour, much less German admin-style humour”