Al Viro wrote: > On Wed, Jun 27, 2007 at 11:05:20PM -0700, Josh Triplett wrote: >> Al Viro wrote: >>> On Thu, Jun 28, 2007 at 01:39:59AM -0400, Pavel Roskin wrote: >>>> Use the actual sizeof values at the compile time to describe the default >>>> target. If sparse is compiled on a 64-bit system, it will default to a >>>> 64-bit system now. >>>> >>>> To force 32-bit operation on 64-bit systems, recognize -m32. Reject >>>> machine options other than -m32 and -m64. >>> NAK. That makes life very painful for cross-builds. >> And the current approach of hard-coding all the sizes doesn't? >> >> While I agree that I'd like a better approach (specifically, I want any Sparse >> build to support any target arch), I don't yet have a solution for that, and >> this patch does at least seem like an improvement over the current hardcoded >> values. > > At least it guarantees behaviour that depends only on the arguments you > pass to sparse and is consistent between the boxen you run sparse _on_. [...] > Having types based on the host sparse is built on is utter insanity - > if anything, we need to be very careful about leaking them into > sparse operations. Just take a look at what portability nightmare > binutils had become due to that approach... Hmmm. OK, I buy that argument. > FWIW, one of the pending patches in my tree makes default size_t unsigned > int, switches it upon -m64 and adds explicit -msize-long for forcing the > same in absense of -m64 (i.e. for 32bit target that has size_t declared > as unsigned long). Sounds good. - Josh Triplett
Attachment:
signature.asc
Description: OpenPGP digital signature
