Now everything is clear, thank you. Have a good weekend =) пт, 31 янв. 2020 г. в 21:01, Rich Felker : > On Fri, Jan 31, 2020 at 08:51:05PM +0300, Андрей Аладьев wrote: > > > Moreover, adding such a thing is not desirable because it adds a > > linear-search of an array of load segments to each relocation > > > > I think it is possible to make this search O(log n). > > This would help if n were large, but in practice it's very small (2-3 > or maybe 4) and the cost is just the code path overhead, which gets > worse if you do that, not the largeness of n. > > > for (j=0; v-p->loadmap->segs[j].p_vaddr >= p->loadmap->segs[j].p_memsz; > > j++); > > > > This code takes first segment that can handle address. It looks possible > to > > create modified list of virtual segments, that won't overlap and make a > > binary search. > > They're non-overlapping anyway but not necessarily sorted, and can't > be simultaneously sorted by addr and p_vaddr since the orders will > differ. > > > > This is not a reasonable tradeoff and it's why I proposed the "hull" > > approach > > > > It may not be safe from maintainability perspective. Library will be > > changed, everybody will forget what part of code was protected by > external > > validation and it will provide unexpected behaviour. Please consider > double > > validation approach: > > You're really not making sense here. What does "protected by external > validation" mean? There is presently nothing being "protected" here; > the discussion is just about more informative errors. If this is used > as a boundary for some sort of safety at some point in the future (as > mentioned before, the benefit of this is probably limited to ldd and > thus not very useful) then it will be done according to constraints > needed to achieve that. > > > external validation in production and debug only mode > > with loadmap like validation. > > We do not have separate "production" and "debug" modes. This kind of > thing (combinatoric build-time options) is what lacks maintainability. > > Rich >