Style fixups for proc.h

2003-02-01 Thread Mark Murray
Hi OK to commit the style fixups below? (They just make sure that all function prototypes have all arguments named, and that all names are protected). int foo(int bar); becomes int foo(int _bar); M Index: proc.h === RCS file:

Re: Style fixups for proc.h

2003-02-01 Thread Julian Elischer
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? On Sat, 1 Feb

Re: Style fixups for proc.h

2003-02-01 Thread Mark Murray
Julian Elischer writes: I don't know about the protection with a '_'. It's not standard and usually the name matches that used in the actual function. When the prototype parameter name matches a local variable, the C compiler (and lint) whine about clashes between names in local/global

Re: Style fixups for proc.h

2003-02-01 Thread Daniel Eischen
On Sat, 1 Feb 2003, Mark Murray wrote: Julian Elischer writes: I don't know about the protection with a '_'. It's not standard and usually the name matches that used in the actual function. When the prototype parameter name matches a local variable, the C compiler (and lint) whine

Re: Style fixups for proc.h

2003-02-01 Thread Matthew Dillon
:Julian Elischer writes: : I don't know about the protection with a '_'. : : It's not standard and usually the name matches that used in the actual : function. : :When the prototype parameter name matches a local variable, the C compiler :(and lint) whine about clashes between names in

Re: Style fixups for proc.h

2003-02-01 Thread Mark Murray
:When the prototype parameter name matches a local variable, the C compiler :(and lint) whine about clashes between names in local/global namespace. I've never in my life heard of this behavior before, what compiler arguments reproduce it? WARNS=5. :2 ways to fix this are to

Re: Style fixups for proc.h

2003-02-01 Thread Steve Kargl
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..

Re: Style fixups for proc.h

2003-02-01 Thread Bakul Shah
Julian Elischer writes: I don't know about the protection with a '_'. It's not standard and usually the name matches that used in the actual function. When the prototype parameter name matches a local variable, the C compiler (and lint) whine about clashes between names in

Re: Style fixups for proc.h

2003-02-01 Thread Juli Mallett
* De: Bakul Shah [EMAIL PROTECTED] [ Data: 2003-02-01 ] [ Subjecte: Re: Style fixups for proc.h ] Julian Elischer writes: I don't know about the protection with a '_'. It's not standard and usually the name matches that used in the actual function. When the prototype

Re: Style fixups for proc.h

2003-02-01 Thread Matthew Dillon
:WARNS=5. This isn't helpful. I tried adding every -W switch in bsd.sys.mk and couldn't reproduce the problem. What compiler option is causing the problem? : :2 ways to fix this are to protect the prototype argument names with the : :_, or to remove the argument name altogether. :

Re: Style fixups for proc.h

2003-02-01 Thread Mark Murray
Why not fix the compiler lint instead of cluttering up declarations? Can we at least get proc.h to have a consistent style of function parameter usage? M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the

Re: Style fixups for proc.h

2003-02-01 Thread Matthew Dillon
:If a named prototype clashes with something in global scope, :isn't it still a shadowing issue? They should probably never :be *in* scope. :-- :Juli Mallett [EMAIL PROTECTED] :AIM: BSDFlata -- IRC: juli on EFnet I finally was able to reproduce the bug. But it's an obvious bug in the

Re: Style fixups for proc.h

2003-02-01 Thread Garrett Wollman
On Sat, 01 Feb 2003 16:02:57 -0800, Bakul Shah [EMAIL PROTECTED] said: I can't see what actual error is avoided by this warning. It's a potential error -- if there were an actual error, it would be an error and not a warning. The issue is simple: Say you have an object and a function declared

Re: Style fixups for proc.h

2003-02-01 Thread Garrett Wollman
On Sat, 1 Feb 2003 19:31:47 -0500 (EST), I wrote: union baz { int foo; struct frotz *gorp; } foobaz; #define foo foobaz.foo Oops... What I meant to say: union baz { int bazu_foo; struct frotz *bazu_gorp;

Re: Style fixups for proc.h

2003-02-01 Thread Mark Murray
Matthew Dillon writes: :WARNS=5. This isn't helpful. I tried adding every -W switch in bsd.sys.mk and couldn't reproduce the problem. What compiler option is causing the problem? I don't know which specific one. Ok, now I'm really confused. How can it not always help?

Re: Style fixups for proc.h

2003-02-01 Thread Matthew Dillon
:I really dislike screwing around with source code to work around :bugs in the the compiler, or lint. Given the choice of underlines :or leaving the arguments unnamed, I would leave them unnamed. Or I :would figure out and remove whatever broken compiler option is generating :

Re: Style fixups for proc.h

2003-02-01 Thread Bakul Shah
I can't see what actual error is avoided by this warning. s/actual/potential/ If a named prototype clashes with something in global scope, isn't it still a shadowing issue? They should probably never be *in* scope. Nothing is being shadowed. Paramater names in a function prototype (as

Re: Style fixups for proc.h

2003-02-01 Thread Julian Elischer
On Sun, 2 Feb 2003, Mark Murray wrote: Why not fix the compiler lint instead of cluttering up declarations? Can we at least get proc.h to have a consistent style of function parameter usage? Sure. let's be consistent with all the other .h files in the kernel. what does a quick census

Re: Style fixups for proc.h

2003-02-01 Thread Giorgos Keramidas
On 2003-02-01 19:31, Garrett Wollman [EMAIL PROTECTED] wrote: On Sat, 01 Feb 2003 16:02:57 -0800, Bakul Shah [EMAIL PROTECTED] said: I can't see what actual error is avoided by this warning. My personal opinion, which is different from what style(9) recommends, is that parameter names should

Re: Style fixups for proc.h

2003-02-01 Thread Terry Lambert
Matthew Dillon wrote: Mark Murray wrote: :Then can we just get the proc.h prototypes into a (any) consistent :style? Yes; no brainer, except where Garrett has indicated (e.g. a function that takes a fromvp and tovp, or other similar arguments). Lets ask ourselves what the goal of the

Re: Style fixups for proc.h

2003-02-01 Thread Andrew Mishchenko
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

Re: Style fixups for proc.h

2003-02-01 Thread Matthew Dillon
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.

Re: Style fixups for proc.h by andrew@driftin.net

2003-02-01 Thread Andrew Mishchenko
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