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_cast(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]>, 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 ...
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 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. 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... -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] "Sentience hurts." 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". -- 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 ...
< 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 ...
> >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 ...
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 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 ...
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
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: > > < 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 ...
< 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 ...
>
> 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 do
> the trick. Here's about the first 5 of the 30 (or so) errors I see:
>
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:
Index: crypto/openssh/pam_ssh/pam_ssh.c
===
RCS file: /home/ncvs/src/crypto/openssh/pam_ssh/pam_ssh.c,v
retrieving revision 1.4
diff -u -r1.4 pam_ssh.c
--- crypto/openssh/pam_ssh/pam_ssh.c2000/03/29 08:24:37 1.4
+++ crypto/openssh/pam_ssh/pam_ssh.c2000/05/22 18:14:51
@@ -86,11 +86,11 @@
* environ at an array of one element equal to NULL).
*/
-SLIST_HEAD(env_head, env_entry);
+SLIST_HEAD(env_head, struct env_entry);
struct env_entry {
char*ee_env;
- SLIST_ENTRY(env_entry) ee_entries;
+ SLIST_ENTRY(struct env_entry)ee_entries;
};
typedef struct env {
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
