[PATCH] convert local constant arrays to static

Denis Vlasenko vda at ilport.com.ua
Thu Feb 23 06:57:17 UTC 2006


On Wednesday 22 February 2006 19:01, Rob Landley wrote:
> On Wednesday 22 February 2006 2:00 am, Denis Vlasenko wrote:
> > Hello,
> >
> > Patch basically does this:
> >
> > -               char *extn[] = {"", ".zip", ".ZIP"};
> > +               static const char *const extn[] = {"", ".zip", ".ZIP"};
> >
> > in several places. '*const' pointers are used instead
> > of just '*' to let compiler check that there is no
> > assignments to array members.
> >
> > Rob, can you look at the hunk where I made cleanenv[]
> > static? I'm not 100% sure it's ok to do so...
>
> Unfortunately, the sucker spits out a warning on gcc 4.0 about passing stuff 
> discarding qualifiers in networking/ifupdown.c, line 769, argument 1.  Adding 
> "const" to the arguments of the function makes it complain about the return 
> statement discarding qualifiers, and attempting to fix up the return value 
> from the function makes it complain that type qualifiers are ignored on a 
> function return type.

You need to add this:

static const struct address_family_t *get_address_family(const struct address_family_t *af[], char *name)
       ^^^^^                                             ^^^^^
{...

> May I also mention that "const int *const name" is _AMAZINGLY_ ugly and serves 
> to hide the fact that name is a pointer?

I just trained myself to read "*const" as "just like * (i.e., we define a pointer)
but you can't assign to it". Compare:

	type_t * p;
	type_t *const p;

I agree that *const is harder to read than *.

> That's far more likely to generate
> bugs than prevent them.  The current set of warnings I'm tring to fix up is
> not an actual bug by the way, this is more extensive infrastructure to get
> the compiler to shut up which is why I _hate_ const.
>
> I try not to project my prejudices about "gee, this is a hideously stupid part 
> of the language that serves no purpose I can see" on other people, but I 
> reverted networking/ifupdown.c because it has warnings and I've spent more 
> time than this is worth trying to make them go away already.

In the case of statics, const is helping to catch bugs of the following kind:

int f() {
	static char *message[] = { "I think we never modify this, so let's make it static" };
	... 1000 lines of code...
	message[0] = "I forgot about it. Next call to f() will have wrong message[0]";
}

static char *const *message[] would prevent it.

> (I hate const.  If the compiler's doing unit-at-a-time then it can tell that 
> this thing is never modified so it can do whatever optimizations are 
> necessary.  Thinking it will somehow reduce bugs by making the code more 
> complicated and harder to read is silly.)

const'ifying the source is a global decision. Using consts in one .h
file and not using them in another .c file won't work.

Pros: prevent some classes of bugs. Allow const data placement in rodata.
Cons: extra effort to get consts right. Bigger and harder to read source code.

It's up to you to decide. Please inform us (busybox list) about your decision.

> The rest of your patch was applied.

Thanks!
--
vda



More information about the busybox mailing list