Another bug in Listbrowser class

8 posts / 0 new
Last post
alfkil
alfkil's picture
Offline
Last seen: 3 weeks 5 days ago
Joined: 2011-05-10 22:02
Another bug in Listbrowser class

Possibly related to this: Previous post

When creating a listbrowser node with less column entries than the number of entries in ColumnInfo (the number of columns), your application crashes.

That is: You have created 3 columns and you try to add a listbrowser node with only 2 entries for LBNA_Column (0 and 1).

Can someone confirm this issue?

salass00
salass00's picture
Offline
Last seen: 3 weeks 6 days ago
Joined: 2011-02-03 11:27
Re: Another bug in Listbrowser class

Not a "bug". The listbrowser just expects that nodes and columninfo should have the same amount of columns because the API and internal structures were not designed for dynamically adding and removing columns.

alfkil
alfkil's picture
Offline
Last seen: 3 weeks 5 days ago
Joined: 2011-05-10 22:02
Re: Another bug in Listbrowser class

Kind of odd that a unit, that allows for dynamic adding and removal should be not designed to do so? Seems a bit counterintuitive. I would argue, that in that case it is an instance of bad design. But of course I could be unaware of certain details in the internal structure.

EDIT: In any case a crash at this point seems highly illegit and suggests, that the mentioned behavior has in fact just not been tested at all.

broadblues
broadblues's picture
Offline
Last seen: 3 months 2 weeks ago
Joined: 2012-05-02 21:48
Re: Another bug in Listbrowser class

Kind of odd that a unit, that allows for dynamic adding and removal at should be not designed to do so?

It's designed for dynamically adding and removing rows not columns.

In any given listbrowser all rows must have the same number of columns and this must match the number specified in the ColumnInfo structure.

The crash is not the result of lack of testing it's rather actually expected as the column number is fixed and if you pass node with the wrong number (at least if less than) then as the browser counts through the nodes it will inevtibaly read past the end of the array.

alfkil
alfkil's picture
Offline
Last seen: 3 weeks 5 days ago
Joined: 2011-05-10 22:02
Re: Another bug in Listbrowser class

The crash is not the result of lack of testing it's rather actually expected as the column number is fixed and if you pass node with the wrong number (at least if less than) then as the browser counts through the nodes it will inevtibaly read past the end of the array.

Could be remedied with a simple if statement? Also, it has not been specified, that columns be given in a specific order, so some kind of generic checking must be already present? I fail to see, why this crash is a necessary result of the algorithm.

broadblues
broadblues's picture
Offline
Last seen: 3 months 2 weeks ago
Joined: 2012-05-02 21:48
Re: Another bug in Listbrowser class

See my comment about "error checking" on your other thread :-)

alfkil
alfkil's picture
Offline
Last seen: 3 weeks 5 days ago
Joined: 2011-05-10 22:02
Re: Another bug in Listbrowser class

The thing I am trying to convey is, that the argument of "little overhead" in response to lack of parameter checking is not sound. There is no conceptual conflict in the creation of list nodes with less than maximum number of column entries. Nor is there any conceptual conflict in trying to create list nodes with any kind of arbitrary enumeration of the column entries defined. The result is, that there seems to be no conceptual standard applying to the functioning of the entities under concern. And that is a clear sign of bad coding design.

salass00
salass00's picture
Offline
Last seen: 3 weeks 6 days ago
Joined: 2011-02-03 11:27
Re: Another bug in Listbrowser class

Bounds checking would need to be done every time a column is accessed in a LB node. It is a lot of work for little to no benefit.

Much better would be to change the columns array into a list so that columns can be added to and removed from LB nodes dynamically.

Log in or register to post comments