Am 22.12.2011 23:16, schrieb Alex Wilson:
On 12/22/11, marcus overhagen<marcusoverhagen@xxxxxxxxx> wrote:However, if invalid parameters are expected as a frequent programming error, it would be much better to validate them and call debugger() on invalid values.I wouldn't expect such errors to be frequent, since programmers can easily determine the valid range of values [0 -> CountItems() - 1]. Indexing is done the same way as it is on arrays and B(Object)List, so I think it's all straight-forward enough to put the onus on the developer.
First of all, sorry for not following through with my initial objection when this code was recently added...
I think it's better that the method checks for a valid range and drops the developer into the debugger. Just consider that we inherited from BeOS the behavior that every BView method call is checking that the parent BWindow is properly locked before proceeding. The overhead here pales in comparison with that and should really not prevent us from adding such checks. The problem I see is that without any checks, it isn't guaranteed that the code triggers a segfault. There may be an odd chance that it doesn't, depending on the memory contents at the invalid location dereferenced. I don't know enough on the subject, but this may even constitude a so called security flaw. The likeliness of wrong parameters being passed should really not be the deciding factor whether or not to add checks. This is a concern for inner, private classes, where one may be able to guarantee that the inputs have been checked before, but not for a library API.
Best regards, -Stephan
