Re: Style fixups for proc.h
On Sat 01 Feb, Steve Kargl wrote: From: Steve Kargl [EMAIL PROTECTED] To: Julian Elischer [EMAIL PROTECTED] Cc: Mark Murray [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Style fixups for proc.h On Sat, Feb 01, 2003 at 03:04:32PM -0800, Julian Elischer wrote: I don't know about the protection with a '_'. It's not standard and usually the name matches that used in the actual function. It's certainly not part of style(9) that I've ever noticed and it's generally noy done that way.. is there a move to do this on all the other files? man 9 style In header files visible to userland applications, prototypes that are visible must use either ``protected'' names (ones beginning with an underscore) or no names with the types. It is preferable to use pro- tected names. E.g., use: voidfunction(int); or: voidfunction(int _fd); Since having actual names in can be helpful if the names are relevant, but having dozens of *_p floating all over the place is not more easily readable, why not leave names out completely when they are not relevant and protect with the underscore when they are? This agrees with style(9). Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Style fixups for proc.h by andrew@driftin.net
On Sat 01 Feb, Matthew Dillon wrote: Well, there is something to be said for trying to avoid userland namespace pollution, but it is still somewhat of a stretch since most userland programs #include standard and system headers before they #include their own, and the includes are typically done before any code. But I see no reason why the underscore methodology would need to be used for kernelland prototypes. C has its problems and we need to live with them, but we shouldn't have to add bogus underscores to prototyped arguments to work around those problems. I'd prefer normally named arguments but if I were given only a choice between underscored named arguments and unnamed arguments, I'd take unnamed arguments hands down. As has been said earlier in this thread, having named arguments can often help new coders learn and help readability (one knows what an argument is for from looking at the header file as opposed to having to look through the C file), which is why I suggested having underscored named arguments when they are useful to have named, and no names when naming them is not useful. Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Request: remove ssh1 fallback
On Wed 23 Oct, David Schultz wrote: In either case, you break compatibility. Say I wanted to SSH from those Solaris boxen to my home machine, for example. (I don't, but that's not the point.) If my SSH server didn't have the SSH 1 fallback, there's nothing I could do from the command line to allow me to log in. I think he means setting the default configuration to disable the fallback; so you would be able to configure it manually to allow SSH1, but the default install would disallow it. Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Request: remove ssh1 fallback
On Wed 23 Oct, Terry Lambert wrote: What if the client machine is a SSH1 Solaris (or Windows) box going into a FreeBSD rackmount? It should *at least* be available as a command line option to the daemon; since some boxes *don't have* consoles at all, it would have the same effect of turning them into a doorstop to disable this flag, once it's available, by default (right now, it just provides both). What could be done with reasonable safety is leave current configs as they are, not changing anything for people upgrading, but setting the default behavior for default installs to no SSH1. Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
