Nico Williams <
nico@...> writes:
> 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
definition.
John,
> Perhaps I'm not following, but it's protected by:
>
> #ifndef _SYS_QUEUE_H_
> #define _SYS_QUEUE_H_
> ...
> #endif
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.
> Nico
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL:
http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord@... PGP key available
_______________________________________________
krbdev mailing list
krbdev@...
https://mailman.mit.edu/mailman/listinfo/krbdev
