> I would hope that the krb5 API itself won't be depending on the
> application using these macros. Greg didn't imply that the API would
> expose the BSD queue.h, so I don't see a problem.
It was unclear if "public" structures would contain the queue pointers.
I had assumed "yes", which implies that k5-queue would necessarily be
required for inclusion of those structures in an application. Obviously
it's not the case for 100% opaque objects where the application never
gets the structure definition.
However, for public structures this means that if an application pulls
in the krb structure header (that pulls in k5-queue) but the application
also wants to use the standard queue, that could result in a double
> Perhaps I'm not following, but it's protected by:
> #ifndef _SYS_QUEUE_H_
> #define _SYS_QUEUE_H_
I would hope that k5-queue does not use #ifndef _SYS_QUEUE_H ...
Moreover, what happens if the definitions change? It would suck if the
library is built with k5-queue but an application with sys/queue,
especially if they don't provide the same ABI. If we're copying the
header then it is possible that they may diverge over time resulting in
an ABI incompatibility.