> jake2000/05/23 13:41:02 PDT
> Log:
> Change the way that the queue(3) structures are declared; don't assume that
> the type argument to *_HEAD and *_ENTRY is a struct.
>
> Suggested by: phk
> Reviewed by:phk
> Approved by:mdodd
>
HEADS UP
Possibl
>
> Is anyone else having trouble compiling the libpam things, because of
> this? I couldn't compile a kernel because of the the assembler changes,
> so I went to do a buildworld, and now I can't get thru a buildworld. I
> tried the suggestion above (do a make includes) but that didn't seem to
< said:
> I've just built a fresh world here; if you use the cvs-crypto from
> internat, it may be broken. I submitted a patch to Mark Murray which
> should fix it, here it is again just in case:
I still think (and am going on record) that this is a REALLY, REALLY
BAD idea.
-GAWollman
To Un
Garrett Wollman wrote:
>
> < said:
>
> > I've just built a fresh world here; if you use the cvs-crypto from
> > internat, it may be broken. I submitted a patch to Mark Murray which
> > should fix it, here it is again just in case:
>
> I still think (and am going on record) that this is a REALL
In message <[EMAIL PROTECTED]> Jake Burkholder writes:
: Some drivers use headers from the installed system during the kernel build,
: and a make world, or at least make includes, is necessary before a new kernel
: can be built.
:
: LINT is affected by this.
Which drivers? Those drivers are, by
In message <[EMAIL PROTECTED]>, Bruce Evans
writes:
>On Wed, 24 May 2000, Garrett Wollman wrote:
>
>> < said:
>>
>> > I've just built a fresh world here; if you use the cvs-crypto from
>> > internat, it may be broken. I submitted a patch to Mark Murray which
>> > should fix it, here it is again
> >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 us
< said:
> It could be an union or class as well...
No, it couldn't be a union. Or rather, it could, but a linked-list
which does not carry any data is somewhat less than useful. If you're
programming in C++, there are much more appropriate ways to construct
abstract data types.
-GAWollman
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
> 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().
> >>
Mike Smith wrote:
>
> > >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
> 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().
> >>
In message <[EMAIL PROTECTED]> "Daniel C. Sobral" writes:
: Last I knew, the only difference between "class" and "struct" was
: whether the default was "public:" or "private:". Of course, C++ has
: changed quite a bit since then, but...
Yes. That's true in C++ today (well, in gcc 2.95) as well.
13 matches
Mail list logo
