2012/12/21 Gabriel Dos Reis <g...@integrable-solutions.net>: > On Fri, Dec 21, 2012 at 3:48 AM, Kai Tietz <ktiet...@googlemail.com> wrote: >> 2012/12/21 Paolo Carlini <paolo.carl...@oracle.com>: >>> On 12/21/2012 10:36 AM, Kai Tietz wrote: >>>> >>>> well, issue isn't that 'long' is always 'ptrdiff_t'. >>> >>> But then, if we just change the type without paying attention to size (and >>> alignment) aren't we looking for BIG ABI trouble?!? >> >> Huh? We have ABI-trouble due long is too small to hold a >> pointer-diff for llp64. Intended is here 'pointer-size' AFAICS in >> code, but with wrong assumption that a 'long' is always long enough. >> >> Btw I just checked all targets we have right now in gcc. The type >> ptrdiff_t is always either 'long', or 'int' (ilp32, lp64), and 'long >> long' for LLP64. Means ptrdiff_t gets always equal (or bigger) to >> biggest pointer-size for target (AFAICS). >> >> Kai > > We must write the codes so that their intents are clear, without > requiring lot of reverse engineering every time one looks at them. If we > intend offset, then clearly ptrdiff_t is the first choice. Solid > reasons must be provided why it can't be ptrdiff_t and such > reasons must be part of the code as comments explaining why > the obvious thing should be discounted. > > - Gaby
Agreed that we are using at some place too complex logic to avoid standard-types we already have ... We need to modify for cxxabi.h header-change also cp/rtti.c, as here the 'long' type-assumption is done, too. instead of using integer_type[itk_long/itk_long_long] there we then have to use instead ptrdiff_type_node. And this is for some targets a possible ABI-change due type_info-record might change size ... for 4.9 this change looks suitable to me, but for 4.8 we should simply check for now for itk_long/itk_long_long here (as done by other patch I've sent). Kai
