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

On Wed, Jul 17, 2024 at 11:15 AM Gedare Bloom <[email protected]> wrote:
>
> On Wed, Jul 17, 2024 at 11:14 AM Sebastian Huber
> <[email protected]> wrote:
> >
> > ----- Am 17. Jul 2024 um 18:57 schrieb Gedare Bloom [email protected]:
> >
> > > On Wed, Jul 17, 2024 at 9:44 AM Sebastian Huber
> > > <[email protected]> wrote:
> > >>
> > >> ----- Am 17. Jul 2024 um 16:29 schrieb Gedare Bloom [email protected]:
> > >>
> > >> > 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.

> > --
> > embedded brains GmbH & Co. KG
> > Herr Sebastian HUBER
> > Dornierstr. 4
> > 82178 Puchheim
> > Germany
> > email: [email protected]
> > 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/