Re: HEADS UP Re: cvs commit: src/crypto/openssh/pam_ssh pam_ssh.c src/gnu/usr.bin/binutils/gdb freebsd-uthread.c src/include mpool.h src/lib/libc/net name6.c src/lib/libc_r/uthread pthread_private.h uthread_file.c src/lib/libncp ncpl_rcfile.c src/lib/libstand if_ether.h ...
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". -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP Re: cvs commit: src/crypto/openssh/pam_ssh pam_ssh.c src/gnu/usr.bin/binutils/gdb freebsd-uthread.c src/include mpool.h src/lib/libc/net name6.c src/lib/libc_r/uthread pthread_private.h uthread_file.c src/lib/libncp ncpl_rcfile.c src/lib/libstand if_ether.h ...
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". Please just let it rest. I don't think Mike's comments are out of line; this was massive breakage regardless of wether world built or not. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP Re: cvs commit: src/crypto/openssh/pam_ssh pam_ssh.c src/gnu/usr.bin/binutils/gdb freebsd-uthread.c src/include mpool.h src/lib/libc/net name6.c src/lib/libc_r/uthread pthread_private.h uthread_file.c src/lib/libncp ncpl_rcfile.c src/lib/libstand if_ether.h ...
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
Re: HEADS UP Re: cvs commit: src/crypto/openssh/pam_ssh pam_ssh.c src/gnu/usr.bin/binutils/gdb freebsd-uthread.c src/include mpool.h src/lib/libc/net name6.c src/lib/libc_r/uthread pthread_private.h uthread_file.c src/lib/libncp ncpl_rcfile.c src/lib/libstand if_ether.h ...
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. Many things have changed since the bad old days of cfront 1.2, not all of them for the better. const_castvoid *(Warner) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP Re: cvs commit: src/crypto/openssh/pam_ssh pam_ssh.c src/gnu/usr.bin/binutils/gdb freebsd-uthread.c src/include mpool.h src/lib/libc/net name6.c src/lib/libc_r/uthread pthread_private.h uthread_file.c src/lib/libncp ncpl_rcfile.c src/lib/libstand if_ether.h ...
In message [EMAIL PROTECTED], Bruce Evans
writes:
On Wed, 24 May 2000, Garrett Wollman wrote:
On Tue, 23 May 2000 20:27:10 -0700, Jake Burkholder [EMAIL PROTECTED] 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.
Especially since most of the queue macros require the type to be a struct
to work. E.g.:
#defineSLIST_REMOVE(head, elm, type, field) do { \
a supposedly general type
if (SLIST_FIRST((head)) == (elm)) { \
SLIST_REMOVE_HEAD((head), field); \
} \
else { \
type *curelm = SLIST_FIRST((head)); \
while (SLIST_NEXT(curelm, field) != (elm)) \
^
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...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP Re: cvs commit: src/crypto/openssh/pam_ssh pam_ssh.c src/gnu/usr.bin/binutils/gdb freebsd-uthread.c src/include mpool.h src/lib/libc/net name6.c src/lib/libc_r/uthread pthread_private.h uthread_file.c src/lib/libncp ncpl_rcfile.c src/lib/libstand if_ether.h ...
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. -- \\ 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
Re: HEADS UP Re: cvs commit: src/crypto/openssh/pam_ssh pam_ssh.c src/gnu/usr.bin/binutils/gdb freebsd-uthread.c src/include mpool.h src/lib/libc/net name6.c src/lib/libc_r/uthread pthread_private.h uthread_file.c src/lib/libncp ncpl_rcfile.c src/lib/libstand if_ether.h ...
On Thu, 25 May 2000 23:33:31 +0200, Poul-Henning Kamp [EMAIL PROTECTED] 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 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP Re: cvs commit: src/crypto/openssh/pam_ssh pam_ssh.c src/gnu/usr.bin/binutils/gdb freebsd-uthread.c src/include mpool.h src/lib/libc/net name6.c src/lib/libc_r/uthread pthread_private.h uthread_file.c src/lib/libncp ncpl_rcfile.c src/lib/libstand if_ether.h ...
On Tue, 23 May 2000 20:27:10 -0700, Jake Burkholder [EMAIL PROTECTED] 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 Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP Re: cvs commit: src/crypto/openssh/pam_ssh pam_ssh.c src/gnu/usr.bin/binutils/gdb freebsd-uthread.c src/include mpool.h src/lib/libc/net name6.c src/lib/libc_r/uthread pthread_private.h uthread_file.c src/lib/libncp ncpl_rcfile.c src/lib/libstand if_ether.h ...
Garrett Wollman wrote: On Tue, 23 May 2000 20:27:10 -0700, Jake Burkholder [EMAIL PROTECTED] 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. I'm not crazy about it either.. breaks compatibility with the original source of the queue macros. What are the advantages? -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000 --- X_.---._/ presently in: Perth v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP Re: cvs commit: src/crypto/openssh/pam_ssh pam_ssh.c src/gnu/usr.bin/binutils/gdb freebsd-uthread.c src/include mpool.h src/lib/libc/net name6.c src/lib/libc_r/uthread pthread_private.h uthread_file.c src/lib/libncp ncpl_rcfile.c src/lib/libstand if_ether.h ...
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 definition, broken. The should absolutely ***NOT*** supposed depend on what's on the system. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
