In my experience, the hypothetical errors the compiler will
catch for you are almost totally nonexistant,
In my experience, it's the not catching existing errors, but
preventing you from doing stupid stuff going forward.
Possibly relevant questions: How many man hours have just
been spent on adding const around the perl source?
I'm not sure what you mean by "have just been spent". I've been
consting the Perl source for probably a year off and on. Call it 200
hours.
In that
time, how many actual bugs have been detected and fixed
by the compiler's const checks
Two that I can think of right off. Sure, it's a pretty low ratio,
but it's also something I can work on as, basically, a background
task when I'm doing other things (usually watching "ER" or "Six Feet
Under" with my wife).
The key, Tom, is that when you're dealing with volunteers, there's no
such thing as wasted time. If I hadn't been working on consting and
refactoring the Perl 5 code, I wouldn't have been doing any work on
the source at all.
Where the real value in consting will be is in Parrot, not Perl 5.
Yes, consting in Perl 5 has a low const-to-bug-found ratio, because
Perl 5 is mature. Parrot, on the other hand, has serious need of
cage cleaning, and consting is the second thing I aim to clean up,
after getting function declaration automated.
(I'm talking real bugs here,
not merely new places where transitive closure of const forces
the addition of more const modifiers to satisfy the compiler).
And I see incorrect consting as a bug because it is a crucial piece
of API documentation that can never go out of date. The Perl 5 API
is filled with functions that look like they should be const, such as
void Perl_sv_copypv(pTHX_ SV *dsv, SV *ssv)
You'd think that would be analogous to strcpy(char *dest, const char
*source), but that's not the case. ssv can get modified (I don't
remember why) and so ssv cannot be const. If there are no consts in
the source, then that's not obvious, because nothing has const.
However, in a proto.h full of consted functions, the lack of a const
tells the user that ssv is not safe from getting touched.
Of course, my sour outlook is much worse because I deal with
C++ most of the time where const is a far more virulent virus
than it is in C.
Good thing we're not in C++.
The consting on p5 has been so long because I've had to retrofit
consts into the source as I go along. It's been long and tedious,
but very rewarding.
The consting on Parrot will not be nearly so bad, because I'm
starting it early. Years from now, when Parrot's API is consted
properly, people will be glad it's there.
I know, I know, nobody agrees. But it is good to get on record
so computer historians 1000 years from now will know there was
one sane voice in the madness :-).
I'm glad you've pleased yourself by scratching that itch on your own
behalf, but what have you done to improve things the codebase
lately? Perhaps I'm missing something, but I see precious little
from you except for this message pissing on the Coverity work. http://
aspn.activestate.com/ASPN/Mail/Message/perl5-porters/3115733
I'd suggest that Perl already has enough cynics and curmudgeons, even
those who've been around for years as you have. Surely you have more
positive skills to apply than knocking down the work of others?
xoxo,
Andy
--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
