So, here we go again. Must have been more than 2 weeks since the last discussion about range checking ...
Maurice Lombardi wrote:
You have said some time ago that check of array addresses was not so important ...
Indeed, it's not so important *to me*. I've had many more trouble with pointer bugs than with indexing bugs. Maybe that's due to my habits (checking indexes more carefully when I write them due to problems in the past) or my kind of programming (probably more with pointers and less with arrays than others) or the fact that index problems can often be easier found with some tools (efence, e.g.) ...
You said also in an other mail that you were not fond of numeric analysis ...
The two are closely related because this kind of lost of days of time is by far the most important for anybody who does numeric analysis programs...
If they'd spent some of these days working on GPC, then GPC might be better in this area. As it's usual with free software, if you want a feature, you can implement it yourself, you can pay someone to do it, or you can just hope.
Correcting this is in my opinion the most urgent thing to do after the 2.1 release.
CBFalconer wrote:
Chiming in with a 'me too'. What is needed is a way to check expressions as they are built, and prior to storing or using to index. It should look something like "check(min,max):boolean" This can be applied to subranges and indices, in fact whereever the compiler has knowledge of extreme allowable values (this includes case indices). If the machine model is a stack machine the model for this is easy.
In the long run the efficiency aspects can be ameliorated by deciding where NOT to call the checking code. This is where the numeric analysis comes in.
For arrays one of the preliminary operations is always to subtract the lower bound, so this can be combined with the check operation. Or you can look at it as being a check of a single value after manipulating into something zero based, but I think the lack of generality there will bite sooner or later.
Sorry, but we've discussed all these issues before, so let me point out again (and hopefully for the last time):
- I know quite well which cases need checking, on the source level. But it's some work to find the places in the compiler.
- We don't want a function. Doing the comparison inline is easy, more efficient (and maybe even smaller WRT code size; I'm not sure and I don't care too much).
- We don't need to worry about low-level optimization. The backend does this perfectly well already.
It's really not like this is very difficult in theory (in the basic version which is probably enough for most), it's just some work to do it, find all cases, test everything, etc. Let's look of the net result of this part of the discussion:
For me: 10 minutes lost For you: I don't know how much time lost For GPC: nothing gained
Not very effective, don't you think? So please, don't start such discussions again unless you have any new suggestions or actually want to help (same goes for porting to gcc-3 and other frequently repeated wishes). I don't react to the number of me-too's I see.
If you really want to help and don't dare to touch the compiler, one thing would be to write some good test programs -- by that, I don't mean 2 programs that contain the obvious cases that everyone thinks about, but a set of programs (maybe on the order of 20-50 programs) that test all conceivable cases, correct and wrong ones, and that meet the criteria of the test suite ...
Frank