1. Indeed, "_t" is reserved namespace by posix but the reality is that a lot of 3rd party
code uses it because it is a useful convention to identify typedefs. To wit:
$ fgrep -r _t /usr/src/external/bsd/ntp/dist | fgrep typedef | wc -l
446
I am picking ntp because it had a conflict with the extra typedefs used in the kernel
(I think it was vaddr_t or paddr_t). We ended up fixing the kernel headers to not
expose them).
2. "Fixing" existing software -- that is not broken -- is incorrect and just busy work: It adds
maintenance and does not solve the problem. After all it is futile to try to find the
possible uses of max_align_t.
3. We strive to provide reference headers that do not contain extra identifiers that
pollute the namespace and we try to adhere with the standards. Exposing
"max_align_t" where we should not goes against our principles.
christos
> On Mar 10, 2020, at 7:54 AM, Kamil Rytarowski <n54%gmx.com@localhost> wrote:
>
> Signed PGP part
> _t is a reserved namespace and nothing 3rd party (at least POSIX) should
> use it.
>
> We checked with Michal and building larger chunks of pkgsrc code had no
> negative effect with exposed max_align_t.
>
> I was responsible for bypassing the max_align_t libc++ definition and
> reusing our homegrown from stddef.h. The motivation was to avoid
> duplicated definition redefined differently (as long double) in libc++,
> as it caused a build failure.
>
> I didn't think about pre-C++11 build issues at that time.
>
> As discussed with the FreeBSD developers in the past, they recommended
> to just go for a solution like:
>
> #if __ISO_C_VISIBLE >= 2011 || __cplusplus >= 201103L
> #ifndef __CLANG_MAX_ALIGN_T_DEFINED
> typedef __max_align_t max_align_t;
> #define __CLANG_MAX_ALIGN_T_DEFINED
> #define _GCC_MAX_ALIGN_T
> #endif
> #endif
>
> and reuse the fallback in LLVM/GCC just as is. As we didn't provide such
> machine I disabled the fallback to our internal definition.
>
> I don't understand what we try fix here and what is broken (what fails
> to build, what is misbehaving) after exposing max_align_t.
>
> On 10.03.2020 12:38, Christos Zoulas wrote:
>> I've been following this discussion and it seems that:
>>
>> 1. upstream is not interested making the library support < c++11
>> 2. finding the correct "max_align_t" is not obvious, but the library wants to
>> 3. "max_align_t" should not be exposed to < c++11
>>
>> Given the above constraints, the simplest solution to move forward seems to be:
>>
>> 1. sed -i -e s/max_align_t/__max_align_t/g *.h
>> 2. edit the file where the typedef is defined and expose "max_align_t" if you are
>> compiling the library or if >= c++11
>>
>> I don't see what all the fuss is about.
>>
>> christos
>>
>>> On Mar 10, 2020, at 7:30 AM, Kamil Rytarowski <n54%gmx.com@localhost> wrote:
>>>
>>> Signed PGP part
>>> On 09.03.2020 18:09, Joerg Sonnenberger wrote:
>>>> On Mon, Mar 09, 2020 at 01:16:58PM +0100, Kamil Rytarowski wrote:
>>>>> Upstream libc++ maintainers are against patching libc++.
>>>>
>>>> I'm buffled how you are arriving at this conclusion. Let me reiterate:
>>>> STOP MESSING UP THE TREE.
>>>>
>>>> Joerg
>>>>
>>>
>>> I'm sorry to come with these conclusions. I checked that the formal
>>> code owner (according to llvm/CODE_OWNERS.TXT) for libc++ is Marshall
>>> Clow (mclow), but he is not a very active in the development process and
>>> we are used to collaborate with other developers in the tree that review
>>> and feedback our patches (especially EricWF).
>>>
>>>
>>> <sanitizer.log>
>>
>
>
>
> <sanitizer.log>
Attachment:
signature.asc
Description: Message signed with OpenPGP