svn commit: trunk/busybox/util-linux

Rob Landley rob at landley.net
Tue Sep 19 21:43:03 UTC 2006


On Tuesday 19 September 2006 9:51 am, Denis Vlasenko wrote:
> On Tuesday 19 September 2006 15:18, Bernhard Fischer wrote:
> > On Mon, Sep 18, 2006 at 10:53:08AM -0400, Rob Landley wrote:
> > >On Sunday 17 September 2006 11:51 am, vda at busybox.net wrote:
> > >> -#define useMtab 0
> > >> -#define fakeIt 0
> > >> +enum {
> > >> +	useMtab = 0,
> > >> +	fakeIt = 0,
> > >> +};
> > >
> > >Ok, your argument a moment ago in favor of using enum was scoping rules, 
and 
> > >here you're making a global enum.
> > >
> > >Anybody else see an inconsistency here?
> > 
> > I don't like these enums. IMHO they are not readable and -- compared to
> > defines -- don't come with any advantage whatsoever.
> 
> Okay, let's say you do
> 
> #define linenumber 0
> 
> What will happen if somebody, somewhere in the jungle of included
> header files, already used "linenumber" as a name for something?

In an applet?  The new #define stomps the earlier one for any lines occurring 
later in the program.

> With enum, you'll get understandable error message.
> 
> With #define, you get no error at the #define site.
> You get weird errors somewhere after that.

If your applet is using a value and you don't know what it is, there's a 
problem.

This is not something in a header file, this is local to an applet's C file.

> Say, putchar(), which is usually a macro, will expand to
> ....; linenumber = 0; .... and you will get "invalid lvalue
> in assignment". Not very easy to figure out.

And you either should know what you changed recently or you should be able to 
track it down to a specific svn version.  We've done this before.

> If putchar will expand to ....; something = linenuber;....,
> you get NO ERROR. You get nasty bug.

You get a behavior change, and you track it down.  I've tracked down much 
worse problems than this.

> In other words: C scope rules and typechecking are a Good Thing.
> We should use them, because they are designed to save us from
> common mistakes.

Are you saying that the above putchar() macro would still work when you made 
linenumber an enum, or are you just saying it would be easier to track down 
the bug?  (If linenumber is an enum and you declared it at a global level, 
and your bog is "something = linenumber" which is _in_ your current scope, 
how exactly is the enum an improvement?  And where did linenumber get 
declared in putchar, anyway?  Wouldn't "int 0;" cause the compiler to throw 
up?

> "error: parameter name omitted" is gcc's idiotic desire to have
> all function parameters named, even those which are unused
> (so that it can happily complain "parameter foo is unused").

Can we suppress specific warnings that we just don't care 
about?  -Wnowarn-stupid?

I definitely intend to take -Werror out for the next release version, right 
now it's there because it was a lot of work to make them go away in the first 
place, and without something like this the suckers build again up over 
time...

Rob
-- 
Never bet against the cheap plastic solution.



More information about the busybox mailing list