[PATCH] libc/include/sys/tree.h: Re-add sys/tree.h

[Chris Johns]

On 18/7/2024 3:27 am, Gedare Bloom wrote:
> On Wed, Jul 17, 2024 at 11:15 AM Gedare Bloom <gedare@rtems.org> wrote:
>>
>> On Wed, Jul 17, 2024 at 11:14 AM Sebastian Huber
>> <sebastian.huber@embedded-brains.de> wrote:
>>>
>>> ----- Am 17. Jul 2024 um 18:57 schrieb Gedare Bloom gedare@rtems.org:
>>>
>>>> On Wed, Jul 17, 2024 at 9:44 AM Sebastian Huber
>>>> <sebastian.huber@embedded-brains.de> wrote:
>>>>>
>>>>> ----- Am 17. Jul 2024 um 16:29 schrieb Gedare Bloom gedare@rtems.org:
>>>>>
>>>>>> This file should not be added in a shared folder. It was a mistake to
>>>>>> put it there in the first place. The problem is that this file is not
>>>>>> a standard interface, it is de facto defined by the upstream (FreeBSD)
>>>>>> and they do not provide backward compatibility in this file as an API.
>>>>>
>>>>> The <sys/tree.h> is also present in other BSD systems, for example:
>>>>>
>>>>> https://man.openbsd.org/tree
>>>>>
>>>>> https://man.netbsd.org/tree.3
>>>>>
>>>> For completeness:
>>>> https://man.freebsd.org/cgi/man.cgi?query=tree&apropos=0&sektion=0&manpath=FreeBSD+14.1-RELEASE+and+Ports&arch=default&format=html
>>>>
>>>>> Which API incompatibility did you observe? FreeBSD releases may break the
>>>>> Application Binary Interface (ABI), but an Application Programming Interface
>>>>> (API) break would surprise me. If the API was extended, then it would be
>>>>> probably easy to add the new API elements to the Newlib version of
>>>>> <sys/tree.h>.
>>>>>
>>>> The problem is with how this header uses CPP macros to generate the
>>>> functional implementation. The functional implementation differs based
>>>> on which header file you include. This has the result that the
>>>> implementation is the API, already a questionable design choice, but
>>>> worse, if you have multiple versions of sys/tree.h, whichever one gets
>>>> included first will determine how the implementation is generated. If
>>>> you have inconsistency in the include order, you end up with different
>>>> functional implementations of the same names. This arises directly
>>>> when one has a tree.h generating rbtrees and a different tree.h
>>>> generating rank-balanced trees.
>>>>
>>>> The problem is indicated by compile-time warnings about redefinitions
>>>> of CPP macros. These warnings are hiding the fact that completely
>>>> different functions can be instantiated depending on which tree.h gets
>>>> picked up.
>>>
>>> Yes, this is true, however, these are Application Binary Interface issues and it happens only if you inconsitently mix differnt versions of <sys/tree.h>. Actually, you can only end up in this mess if the API is compatible.
>>>
>> OK, that is fair.
>>
>>> Again, I would simply remove <sys/tree.h> from libbsd, monitor the FreeBSD changes, and after evaluation update the Newlib version if there are benefits.
>>>
>> I'm not opposed to this route, but, we now wind up in the same problem
>> in newlib: cygwin would like to update tree.h, but rtems would like to
>> keep the rbtree version.
>>
> Nevermind, we fixed the RTEMS side. The only remaining problem is when
> the application (or library such as libbsd) would prefer a different
> version of tree.h. I think we can live with just restoring the tree.h
> for now, or someone can provide an updated one also.
> 
> On the RTEMS side, someone needs to remove tree.h from our libbsd.
> 

I am not comfortable with the return of this header to newlib and consider the
addition questionable. Corinna is right saying the removal of headers in the
shared area can break existing user code and continuing this path the addition
of headers like this can also break existing applications. We do not know if
users have headers like this in their code base. I feel users of newlib are in
the best position to know which version of the header they want to depend on. I
know of a couple of archived projects I worked on with imported FreeBSD code the
addition of this header would have caused problems.

Does newlib have a process for determining the addition of headers to the shared
area?

Chris