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
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.
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
On Sat, 1 Feb 2003, Matthew Dillon wrote:
> sys/acl.h -- looks like the authors tried to use the underscore technique
> but forgot a couple.
Actually, the pattern is that the function prototypes exposed to userspace
are prefixed with '_' to prevent interfering with the appli
> Technically, the compiler doesn't need prototypes at all; they
> are merely a band-aid for the compiler vendors, who did not want
> to have to deal with changing object file format.
IMHO the value of prototypes is in documenting a function
interface rather than for the vendors. Compilers of
lan
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
On 2003-02-01 19:31, Garrett Wollman <[EMAIL PROTECTED]> wrote:
> < 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 be omitted for all functions, EXCEPT
> those with ambig
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
> > 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
:>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
:
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
< 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;
} foobaz;
#define foo foobaz.ba
< 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 in global scope:
int foo;
/* many lines of de
: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
> 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 t
: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 altogeth
* 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 usua
> 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
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
> :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
: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/g
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 lin
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 na
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 2003,
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: /ho
25 matches
Mail list logo
