> In message <[EMAIL PROTECTED]>, Mike Smith writes:
> >> >I objected to a recent commit hiding the fact that this is
> >> >"(elm)->field.sle_next". Anyway, curelm must be a pointer to a struct.
> >> >Not just any struct; the struct must contain a "field" declared using
> >> >SLIST_ENTRY().
> >>
> >> It could be an union or class as well...
> >
> >It would not be very useful if it were a union; the class issue is valid
> >(although you could trivially use a struct contained within a class and a
> >parent reference) but definitely not a good enough argument to support
> >the massive breakage this otherwise entails.
>
> I have yet to see any signs of "massive breakage".
Try "source-level incompatibility with everyone else that uses these
interfaces" (eg. all the other BSDs, OS/X, AIX, etc.)
The queue macros are a stable, widely-used API. If you're going to
change their calling conventions, simple commonsense behooves you to
rename them as well.
--
\\ Give a man a fish, and you feed him for a day. \\ Mike Smith
\\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED]
\\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
