View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0000325LDMud 3.6Generalpublic2004-12-17 11:592022-10-06 21:17
Reportermenaures Assigned ToGnomi  
PrioritynormalSeverityminorReproducibilityalways
Status assignedResolutionreopened 
Summary0000325: array index range inconsistency
DescriptionIndexing an array by range [x..y] always works, even for negative ranges. However, if you try to assign new values to the indexed part of the array, you get a Lower/Upper range index out of bounds Runtime-Error.

Example:
   
({0,1,2,3})[-3..1]
    -> ({0,1})
    
({0,1,2,3})[-3..1] = ({4,5})
    -> Lower range index out of bounds: -3, size: 4.

({0,1,2,3})[2..5] = ({6,7,8})
    -> Upper range index out of bounds: 5, size: 4.

I like sloppyness (to a certain degree), it's actually sad to see some of it fade away in 3.3. I'm not keen on this half-and-half sloppyness, however. I'd prefer these ranges to work at all times, or never.

Now for something not completely unexpected:

({0,1,2,3})[4..-1] = ({9})
    -> ({0,1,2,3,9,0,1,2,3})

Where did that 'out of bounds' error go here? And what's with the result? Although the behaviour is half documented, it doesn't make any sense to me.
TagsNo tags attached.

Activities

lars

2004-12-18 15:09

reporter   ~0000260

While I agree that the array indexing should work the same all the time, I feel uncomfortable to make the indexing for retrieval stricter as it is right now because I'm afraid that it would break existing code (I remember the problems I had when I disallowed indexing past the end of strings). At the same time I don't want to relax the bounds checking on the assignment simply because I dislike sloppy programming.

What I will do is
 - throw an error for the last case (assignment to a negative range)
 - in 3.3 out-of-bounds ranges for retrieval will generate a warning.

lars

2004-12-18 17:51

reporter   ~0000261

Ok, not really resolved on all counts, but the array range handling will be with us for a while either way.

I implemented the changes I wrote about in my bug note in 3.2.11-dev.689 and 3.3.531.

menaures

2004-12-20 07:33

reporter   ~0000262

If you dislike sloppy programming, do you intend to remove all sloppy elements from LPC? That would change the language quite a lot if you think about it. I'd rather keep the sloppyness, add sloppyness even, but in a clearly defined, well documented and consistent manner. Then you'd no longer have to think of it as sloppy, but rather a cool feature of the language.

peng

2004-12-20 10:06

reporter   ~0000263

The change for the warnings for out-of-bounds-ranges gave is a huge amount of warnings, and I don't like them. There is no broken code at all and fixing all the places where out-of-bound-ranges could occur wastes our time and is inefficient, since it brings a lot more code to write (every index has to check against sizeof) and no better code at all.
So I've thrown out this change since its pretty useless.

The error for the asignement case is ok.

malc

2004-12-21 00:11

reporter   ~0000264

I have an idea...maybe it's useless, maybe not. I agree with Lars solution on this issue. However, I can also see Peng's viwepoint, and I'm sure lots of people would have problems like that.

I also think that people starting fresh, with new code/libs, whatever, ought to do it right the first time, since they have no legacy code to support.

So my idea is, in 3.3, make the default like the changes Lars made. Add a --enable-sloppy-code (or whatever) to allow the behavior similar to what Peng/Menaures wants. As time goes on and Lars cleans up LPC, making it a better language, more of the existing code can be added to this enable option. All the while, defaulting to good, clean code constraints that new libs would (hopefully) take advantage of. Maybe it would make the source too convoluted, but I really dislike sloppy programming as well.

-Malc

lars

2004-12-21 15:01

reporter   ~0000265

While I am certainly nudging LPC into a direction with stricter checking, it will never be a fully checked language simply because there is too much code relying on the old behavior. Peng's comment is a good illustration for it.

Now, as far as these array bounds are concerned, my thinking no goes into the direction to couple the warnings with the no-warn-deprecated pragma, as it is already done for string indexing. If the two checks however are disconnected (read: code which wants to check string indices, but not array range indices), a new pragma just for the bounds checking would be in order.

lars

2004-12-22 02:08

reporter   ~0000267

The array range indexing warnings in 3.3 are as of 3.3.632 controlled by the warn-deprecated pragma.

zesstra

2009-01-08 05:48

administrator   ~0000862

Do have to do anything more here? Do we need the additional pragma Lars mentioned? If not, I believe this should be closed.

Gnomi

2009-01-08 06:36

manager   ~0000866

We have to decide, which way to go for 3.5, as deprecated behavior will likely be removed there.

zesstra

2011-02-14 14:07

administrator   ~0001976

IMHO, there some different cases:

Arrays:
a) indexing past end of array: is already an error
b) indexing with negative ranges for assignment: is an error
c) indexing with negative ranges for retrieval / Out-of-bounds lower range limits: Actually, I vote for error, because I assume they are not too common and I perceive them as unreasonable from the beginning.
d) Out-of-bounds (upper) range limits: are probably far more common and, so far, they are actually not deprecated. I don't even have an idea, how many we might have in MG. Maybe we should deprecate them first?

Strings:
e) Indexing past string end by more then one: already forbidden.
f) indexing with negative ranges for retrieval: like c), disallow them.
g) Indexing past string end: they are really common in MG. And since there are few people caring about them, I see only very slow improvement. In my experience, the most often issue here is ""[0] (most people assume, there is an input and want to have the first char). I am thinking about the following: start with making it an error for strings != "" and keep the deprecated warning for some more time for ""? That would reduce the sudden impact of a huge number of errors but make the point, that they will be gone at some point?

Gnomi

2022-10-06 21:17

manager   ~0002705

We target LDMud 3.7 for making problematic indexing expressions errors.

In the meanwhile we'll extend the range_check pragma to strings to propagate similar behavior as with arrays.

Issue History

Date Modified Username Field Change
2004-12-17 11:59 menaures New Issue
2004-12-18 15:09 lars Note Added: 0000260
2004-12-18 17:51 lars Status new => resolved
2004-12-18 17:51 lars Resolution open => fixed
2004-12-18 17:51 lars Assigned To => lars
2004-12-18 17:51 lars Note Added: 0000261
2004-12-18 17:51 lars Assigned To lars =>
2004-12-20 07:33 menaures Status resolved => feedback
2004-12-20 07:33 menaures Resolution fixed => reopened
2004-12-20 07:33 menaures Note Added: 0000262
2004-12-20 10:06 peng Note Added: 0000263
2004-12-21 00:11 malc Note Added: 0000264
2004-12-21 15:01 lars Note Added: 0000265
2004-12-22 02:08 lars Note Added: 0000267
2004-12-29 01:33 lars Project LDMud 3.2-dev => LDMud 3.3
2009-01-08 05:48 zesstra Note Added: 0000862
2009-01-08 06:36 Gnomi Note Added: 0000866
2009-05-10 15:34 zesstra Project LDMud 3.3 => LDMud 3.5
2011-02-14 14:07 zesstra Note Added: 0001976
2011-02-14 17:02 zesstra Target Version => 3.5.0
2017-10-04 19:38 zesstra Project LDMud 3.5 => LDMud 3.6
2017-10-04 19:38 zesstra Category Runtime => General
2022-10-06 21:17 Gnomi Note Added: 0002705
2022-10-06 21:17 Gnomi Assigned To => Gnomi
2022-10-06 21:17 Gnomi Status feedback => assigned