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

[Sebastian Huber]

----- 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.

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.

-- 
embedded brains GmbH & Co. KG
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/