redirect to gcc-help samboy wrote: > Wasn't sure whether to post this to gcc Dev or Patches so its both > to start with. > > Its my first posting to this forum so first some background: > > I have a storage application to which I can record or retrieve > files. Its multi-process C/C++ compiled to run on the SPARC > platform. The problem is the maximum file size which can be stored > is 4GB due to the size being internally conveyed using an unsigned > integer. I need to extend the range so it accepts much larger files > i.e. convert all uints to long longs. The approach at first was to > work through the code line-by-line to locate and upsize all > variables as required. The problem is there's almost a million lines > of code and no guarantee every instance of filesize usage will be > located & upsized. Another more elegant approach which came to mind > was to somehow 'trap' the occurrence of *unsigned* integer > overflow...or should that be wrapping - yes I know its completely > acceptable behaviour. If I could get gcc to do this for me I could > simply run a full suite of end-to-end functional testing then wait > for the trap to fire and abort. After each abort I can identify the > undersized variable (via the backtrace) then apply a fix and repeat > the process. This approach guarantees I'll target all variables > restricting >4GB file records. > > I'm not for a moment suggesting this be added as an option to > gcc. I'm just wanting to build a temporary tool to serve a purpose > as outlined above. Want I'm looking for are some fast-track, > high-level pointers as to how to achieve this. > > Bear in mind I've spent a good week gazing at the gcc source but > need some guidance to go forward. As a starting point I've had a > stab at modifying the -ftrapv option to work with unsigned int > arithmetic. Preliminary testing appears to work ok with test apps > aborting when wrapping occurs (I'm also mindful of -ftrapv possibly > being flaky according to some other posts). > > What I'm desperately lacking is the ability to also trap/abort when > ANY unsigned int be it a function arg, return variable, local > variable, etc WRAPS on being assigned or passed a value to large in > RUNTIME. I think this is going to be impractical. A lot of address arithmetic adjusts pointers by adding large negative constants. We know, for example, that $SP + 0xfffffff0 is 16 bytes below the stack pointer. This happens all the time. Andrew.
