I do not think we have to absolutely support C11. We require C++ compiler that is on C++11 standard. If we need to interact with external C code for some reasons,. we can, via extern "C". from within C++.file, for exported functions- As for .c files currently in the codebase, I see no reason why they need to stay .c forever, and no reason why they can't be renamed to .cc, if they require this "yield" . It is not an insurmountable problem. If anything, this will add some good warnings and some type safety
On Fri, May 16, 2025 at 10:21 PM Nikita Malyavin via developers < developers@lists.mariadb.org> wrote: > Sergey, > > I've enabled c11 for parsec plugin at first. Then it ran in a pile of > problems with threads.h availability an ended up in removing c11 support. > > https://github.com/mariadb-corporation/mariadb-connector-c/commit/b827743c27063e9f614dba4c731719240060e4ad > > Still, even with c99 we can have our own threads.h providing > (C11-)standard-compatible names! > > Btw, I recall some progress on "replacing the ugly atomics", namely: > https://github.com/MariaDB/server/pull/2961 > > Regards, > Nikita > > On Fri, 16 May 2025 at 21:31, Sergey Vojtovich <svojtov...@gmail.com> > wrote: > >> Hi Nikita, >> >> Back, when I was writing the original e-mail I didn't realize that we're >> still on C99. >> Yes, we'll definitely have to have different interfaces. I wonder if >> we're considering >> moving towards C11. Then we could probably try disabling our >> pthread_yield() and >> see if thrd_yield() is available on all supported platforms. >> >> Offtop: I really can't wait when we can finish our ugly atomics. Both us >> and MySQL >> team have wasted enormous resources maintaining it. Not talking about >> users suffering >> from bugs. >> >> Below is atomics pain that I alone had to experience. It is most probably >> an incomplete >> list of my commits. Hope it explains my left eye twitching when I see >> non-standard stuff >> when standard replacement is available. >> >> c0ebb3f38811c6a0e3e2b49b3ae40b4ea0c2b0e9 >> 6192f0bffa798c01acc85db9f427ed02234aead4 >> 53360fd45f89e9b16aac69625820988702a339ee >> 82ce2a2503a95e8bdc76c351a87e98c93445a433 >> 40497577ffd9f85557b15e08ad913f627b2e9530 >> c01c819209fdf09b4ba95f34d87d0617776f47cd >> 4472a0ef95ba3257125f5aee0b2b953acc43364d >> ed313e8a92a836422b9ae7b9ecf11c44ed4d5d66 >> e13459a11eb5938b54b88c7a1529491df6dd3b49 >> 6bd76f8b7e086ab7cf0249a05277ff552e564554 >> edf6354bd6389ce1ca79591fe79deef4df6eca95 >> f31a89191f6b1679d9f8b584aa95fe006182ee7d >> 3d1a7cba71f6c843639f0b9a48b12017ff610112 >> d055e28f61ef44f2fdbd139edcaf191c96d14e68 >> f4d885c4e9d929639b7075b7382b439f0b4e3cc1 >> 5608a737ea7b5630452957b82deff4c76406041e >> 2b47f8ff03845f7ffe2fa3bd583dd4123dae2b61 >> 8303aded294ce905bbc513e7ee42623d5f1fdb50 >> bb7e84b79ab5243392e3691c27d6d64566e26b39 >> 8d010c44ef6f156566bcd5ff7fbdcf23ef96e92e >> 68a853732750902fbd97e8ddd1a7f264f9b199c9 >> fb7caad72b5c37e96c69aad63f9589f8b56855d6 >> 1a1749e38c774ce3a3493da2410b19ebe71eccb5 >> c73e77da0fa0fbdb4be5bfa1f4e441b06d1d91f9 >> 57d20f1132df71e3b9aca998bcc31dfd62c942b3 >> 5b624f00fc0e6fa0a5a676d3ec445f62c0fb75ec >> 51bb18f989d198aa648b2481865abd0734520d35 >> b04f2a0f01902d11e21afb690e14d12d2c464184 >> 03e461634d725a66917f8161443710f4338a5b1e >> 90377b8028e0103f967d81fd0cbb8ede99d8215a >> 8023fc6d453aebb2554289d4ed2ab595093a0f14 >> 4abdd798f75e345f8692118634c464073de2cda5 >> 67dbfe6e9ced31ce1e4bb2c60ffbb25c2055c6ec >> 5c657e9fa55787de4cb10c81a7a0459be48844d4 >> 2e5d35961d87e073a9809bbc03813f45d246cbec >> 601f45fdcd72ddd357ad12f39786a7c74423fdde >> 6a150e26d94a75b0b72acc418c2532592fd769e5 >> e976c7dbf20a997c5ba4e9e780848a01b392dd24 >> dab38ce0232f248843e9a53671ab4fa1d0620e72 >> 4404ee29010efe02292373411991e4433a9e57bd >> 9581c4a8f5d6c87a6d34c6d3b826c32bf7f15143 >> e60dc209d492e237234dac63293e33558a0daba7 >> 8c82ca171e562a9d55c5c59a02ead2567212c67b >> d93653bf968ebdaecaace449808577100821cc8d >> b1c3e6c2f27b9da5a4a6bc75f1cf6a4b1d7e3127 >> de32e66336a387bb0391a9861b927799ed007a97 >> edde1f6e0d5f5a0115a5253c9b8d428af132f2d1 >> 66ec8adb77856d5fa6b77edf3ee8471576c30938 >> dbd40edfe680ebaea529b97c3dafa20cb1f40f4e >> 4ef481f5bce5f1ed6c21fc03a65a2d844e5729f8 >> 5cc6b48f39c7c8ec9c5a56d6ac6e639bd660480f >> f401ba477ce66b66b8db5a52eb39e0d7d7b97eb3 >> 0ce7f6b0bf68df34adcd22b864f0ddb37218297c >> 830a7c67a4eefa1091bad4b60617309b9f299c96 >> dc90234bda3e2074179a3e54c09a7c9694e69965 >> adc30ecab52c661689b18045a69b607ee6d42495 >> 28d627392b3ea39ceefd8df7451813da660bf19d >> fbe2a5b7d691f9742053623517e7fd8639562e63 >> 54b3fd25813117ab8eaa6c22a963ee16c0dec224 >> 656a702ca9318c58fde97e19ba7b242d11c05c56 >> c6a00544ff948dc3eafba0e7f0db39ddb352a3b1 >> 66bca0dfa9909ff4078a9973d35c2c80e1927d07 >> e2d96e8a16704c02248c9039028f9de17c887846 >> 9e37537c4e9c8b5cc5aff75b6e891be4cd877573 >> c66db377d75b40c42f336223ac865e4820698e55 >> 39a8caa51c115e7750c2355374413056932665eb >> 65083ba64c4d77b5821816bda1bbed77f6c7961a >> e9a5f288f21c15ec6b4d2dd3d654a320904bb1bf >> 81f700015e746ac590b55bcb21bf21ba0d6febfc >> 5679a2b6b342abc9d80bcf784a1a35f240be9d87 >> 9836fd5d131e405106508a5f706268e371418e05 >> e813f9b9b3a087910b94ffeda968b53f9fca4311 >> 71e11bce34339a69576321d6c40838fa65208dc7 >> 1369e70b561a53dd77da3c0b87217cf2d6c8328d >> 8f9999b5fc658431cac66cf07b51b3f469faa20a >> bb9928160fce03c64bbf753e7eafbdbd95255110 >> 8ff3b892aeac2e320d701652539476c4d9e7b591 >> c23399d3de8275c75b833e6fb64ed4efc433fb7a >> 81f280789b30c070ce6e854dddcd59b28b81af7a >> c10e523d78756348d7128aff4bc00dcef8a0bec9 >> 77a5dab5a279572b680383d6d6c0a09e404fffd9 >> 1029b22feb8d9768df9e8b7b0344e2961bf82659 >> c60095a818dce92838940525899a13a05633d148 >> >> Regards, >> Sergey >> >> On Fri, May 16, 2025 at 10:28 PM Nikita Malyavin via developers < >> developers@lists.mariadb.org> wrote: >> >>> Just want to add, that I think it's fine to have two different >>> interfaces for communicating with OS: one for C and another one for C++, >>> just as we use new(mem_root) in C++ and we have alloc_root for C. Same for >>> atomics. >>> >>> And if we'll have to support more (older) platforms, the library stuff >>> is easily coverable with similar compatibility layers for C++. >>> _______________________________________________ >>> developers mailing list -- developers@lists.mariadb.org >>> To unsubscribe send an email to developers-le...@lists.mariadb.org >>> >> > > -- > Yours truly, > Nikita Malyavin > _______________________________________________ > developers mailing list -- developers@lists.mariadb.org > To unsubscribe send an email to developers-le...@lists.mariadb.org >
_______________________________________________ developers mailing list -- developers@lists.mariadb.org To unsubscribe send an email to developers-le...@lists.mariadb.org
