Re: in which we present an ugly hack to make sys/queue.h CIRCLEQ work

[Dennis Ferguson <dennis.c.ferguson%gmail.com@localhost>]

On 20 Nov, 2013, at 01:54 , matthew green <mrg%eterna.com.au@localhost> 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