On Mon, Apr 24, 2023 at 12:57 PM Stephen Smalley <stephen.smalley.work@xxxxxxxxx> wrote: > > On Mon, Apr 24, 2023 at 12:38 PM James Carter <jwcart2@xxxxxxxxx> wrote: > > > > On Fri, Apr 21, 2023 at 11:27 AM Stephen Smalley > > <stephen.smalley.work@xxxxxxxxx> wrote: > > > > > > On Thu, Apr 20, 2023 at 11:41 AM Christian Göttsche > > > <cgzones@xxxxxxxxxxxxxx> wrote: > > > > > > > > Avoid using the identifier `bool` to improve support with future C > > > > standards. C23 is about to make `bool` a predefined macro (see N2654). > > > > > > > > Since the type `cond_expr_t` is part of the public API it will break > > > > client applications. A quick search of the code in Debian shows only > > > > usages in checkpolicy and setools. > > > > > > NB Header files under the sepol/policydb subdirectory are not part of > > > the libsepol shared library API/ABI and thus changes there are not > > > considered to be API/ABI changes. They should only affect users of the > > > static libsepol and there is no warranty for them. > > > > > > > So should that paragraph be removed or should it say something like: > > "While header files under the sepol/policydb subdirectory are not part > > of the libsepol shared library API/ABI, these changes will break > > setools."? > > Is setools using the shared libsepol or the static one? > It is python. I know the policyrep part includes sepol/policydb/conditional.h Jim > Also wondering if we have violated the original intent here - I see > that #include's of sepol/policydb/policydb.h have crept into public > API headers in include/sepol/*.h. That was never supposed to happen. > They were only supposed to use the encapsulated sepol/policydb.h that > doesn't expose the internals. > > Do we have users of the shared library that are now tied to the > policydb data structures? setools was the only thing (that I know of) that broke when we changed how the filename transitions were stored in the policy. Jim
