Page MenuHomePhabricator

elementary: make sure that our index for the maximum number of object is actually unsigned int bound.
ClosedPublic

Authored by cedric on Dec 19 2019, 10:53 AM.

Diff Detail

Repository
rEFL core/efl
Branch
T8351-devs/cedric/cv-focus
Lint
Lint OK
Unit
No Unit Test Coverage
Build Status
Buildable 15048
cedric created this revision.Dec 19 2019, 10:53 AM

Mhm, this needs more "things" i think.

  • grid pm still returns -1
  • list pm still returns -1
  • collection still uses unsigned int
  • collection_view still checks for id < 0.

In general, i don't understand why this has to be unsigned...

Mhm, this needs more "things" i think.

  • grid pm still returns -1
  • list pm still returns -1
  • collection still uses unsigned int
  • collection_view still checks for id < 0.

Need fixing. Will look at them.

In general, i don't understand why this has to be unsigned...

The unsigned int is the upper limit of the maximum amount of information you can carry in a model. For example your facebook or twitter history is limited to that much forever. The higher limit, we build in now, is I would think the better for the future.

cedric updated this revision to Diff 27676.Dec 19 2019, 3:35 PM

rebase, address other component not using unsigned int and side effect fix the bug of over shooting upper limit of objects.

Mhm, this needs more "things" i think.

  • grid pm still returns -1
  • list pm still returns -1
  • collection still uses unsigned int
  • collection_view still checks for id < 0.

Need fixing. Will look at them.

In general, i don't understand why this has to be unsigned...

The unsigned int is the upper limit of the maximum amount of information you can carry in a model. For example your facebook or twitter history is limited to that much forever. The higher limit, we build in now, is I would think the better for the future.

Mhm, but then we already have a problem, you can have at MAX INT_MAX items in a collection, as the index in item is a signed int.

Mhm, but then we already have a problem, you can have at MAX INT_MAX items in a collection, as the index in item is a signed int.

Collection is not really a problem here as it will never be possible in term of performance to reach even close to INT_MAX (If we reach on a modern PC SHORT_MAX as a limit, I will be happy). In the case of CollectionView, this is still a possibly doable goal.

bu5hm4n added a comment.EditedDec 20 2019, 9:34 AM

Mhm, but then we already have a problem, you can have at MAX INT_MAX items in a collection, as the index in item is a signed int.

Collection is not really a problem here as it will never be possible in term of performance to reach even close to INT_MAX (If we reach on a modern PC SHORT_MAX as a limit, I will be happy). In the case of CollectionView, this is still a possibly doable goal.

No no, item is the problem. And we use item in CV as well.
And the index in a item is int.

No no, item is the problem. And we use item in CV as well.
And the index in a item is int.

Oh dang, why! I didn't even know we had that there... CV is not using it nor filling it properly I would bet.

No no, item is the problem. And we use item in CV as well.
And the index in a item is int.

Oh dang, why! I didn't even know we had that there... CV is not using it nor filling it properly I would bet.

Mhm, I hope :)

bu5hm4n accepted this revision.Dec 27 2019, 2:35 AM
bu5hm4n added inline comments.
src/lib/elementary/efl_ui_position_manager_entity.eo
110

... F...O...R...M...A...T...T...I...N...G...

This revision is now accepted and ready to land.Dec 27 2019, 2:35 AM
Closed by commit rEFL4624b56bedad: elementary: make sure that our index for the maximum number of object is… (authored by cedric, committed by Marcel Hollerbach <mail@marcel-hollerbach.de>). · Explain WhyDec 27 2019, 2:37 AM
This revision was automatically updated to reflect the committed changes.