On 20 Nov, 2013, at 01:54 , matthew green <m...@eterna.com.au> wrote: > unfortunately, changing these macros to be strictly C requires changing > the ABI of them, and while we are going to consider such a change, in > the interest of getting things working we present the following hack. > it was inspired by David Holland, and we considered placing it in > sys/cdefs.h for other consumers, but as queue.h currently only relies > on the presence of "NULL" combined with the need for "<sys/queue.h>" > to work correctly for the tools build (which may be on non-netbsd > platforms.)
I may be misunderstanding something, but it seems like this might preserve the ABI (e.g. old binaries with a newly-compiled library) but still represents a change to the API for anything newly compiled(?). That is, doesn't this code from the kernel have the same problem that the macros themselves have, or am I missing something? /* * sigclear: * * Clear all pending signals in the specified set. */ void sigclear(sigpend_t *sp, const sigset_t *mask, ksiginfoq_t *kq) { ksiginfo_t *ksi, *next; if (mask == NULL) sigemptyset(&sp->sp_set); else sigminusset(mask, &sp->sp_set); ksi = CIRCLEQ_FIRST(&sp->sp_info); for (; ksi != (void *)&sp->sp_info; ksi = next) { next = CIRCLEQ_NEXT(ksi, ksi_list); if (mask == NULL || sigismember(mask, ksi->ksi_signo)) { CIRCLEQ_REMOVE(&sp->sp_info, ksi, ksi_list); KASSERT((ksi->ksi_flags & KSI_FROMPOOL) != 0); KASSERT((ksi->ksi_flags & KSI_QUEUED) != 0); CIRCLEQ_INSERT_TAIL(kq, ksi, ksi_list); } } } So is the plan to add the ugly inline to the CIRCLEQ_* macro definitions, and then fix each program which uses the macros with the same ugly inline when they are compiled by the new compiler? If that's the plan then it seems like it might be better to know what the final solution looks like before changing any code which uses the CIRCLEQ macros, so that any code which needs to be fixed just needs to be fixed once. Dennis Ferguson