strings and constness

[Rob Landley]

On Saturday 17 June 2006 9:07 pm, Erik Hovland wrote:
> On Sat, Jun 17, 2006 at 07:58:00PM -0400, Rob Landley wrote:
> > On Tuesday 13 June 2006 11:19 pm, Erik Hovland wrote:
> > > > >See my post and patch to utils.c and utils.h where I did this for
> > > > >another function:
> > > > >http://busybox.net/lists/busybox/2006-June/022287.html
> > > >
> > > > I see that now, I thought it was a typo since my compiler threw a
> > > > warning about it.  If there are valid space savings for it, we need
> > > > to find a way to suppress the warning.
> > >
> > > If you want to make the string const, put the const before the *.
> >
> > Also, when we have to typecast our way around this crap (as in
> > skip_whitespace() in libbb where half the users typecast the return value
> > back to a normal char * when they use it, but it _is_ a normal char * to
> > begin with...)
> >
> > I'm not a fan of const.  Really.
>
> I think that the compiler could care a flip about whether you are a
> fanatic of const.

The words "fan" and "fanatic" have diverged rather a lot in the last century.  
And "terrific" no longer means "inspiring terror".  "Spectacular" is still 
related to drawing spectators, but has other connotations as well.

Just FYI.

> I could really care less about const either. I think 
> you probably agree that there is only one thing that will decide whether
> const should be used or not, size of binary.

On which compiler version?  If it's an optimization for gcc 2.95 but has no 
effect on gcc 4.1, which is likely to be still relevant in 3 years?

> But if one is going to use const, they should do it right and at least
> understand what the placement of const regarding the * operator does to
> the string.

One reason I dislike is it having to understand (and maintain) non-obvious 
rules like that.

> I have submitted two patches in so many weeks that 
> corrected const.

Needing to do this strikes me as a bad thing.  Do current compilers benefit 
from this, or just old ones?  And by how much?  This never came up in the 
discussion, that I'm aware of...

> Both came after commits that put const in the wrong 
> spot and generated warnings. I think we all could do without those sorts
> of mistakes so we can get to doing the work we want to do.

Yeah.  Avoid using const.

I just threw "#define const" at the top of libbb.h, and fixed up half a dozen 
files that broke when I did that (because they didn't #include libbb.h at the 
top), and the result was actually 1500 bytes _smaller_.  By not having 
anything say const anywhere.  (The resulting binary was about 2k smaller as 
well.)

Just FYI.  With gcc 4.0.3.

> E

Rob
-- 
Never bet against the cheap plastic solution.