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

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.

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