On Tue, Jan 24, 2017 at 4:08 PM, Dibyendu Majumdar <mobile@xxxxxxxxxxxxxxx> wrote: > Hi Luc, > > On 24 January 2017 at 14:47, Luc Van Oostenryck > <luc.vanoostenryck@xxxxxxxxx> wrote: >> On Tue, Jan 24, 2017 at 02:23:13PM +0000, Dibyendu Majumdar wrote: >>> I am working on porting Sparse to Windows, and I noticed that in >>> 64-bit architecture the bits_in_long is set to 64. This is not true >>> for Windows where long is 32 bits on a 64-bit machine. I was wondering >>> if I just need to set this parameter to 32 or if there are other >>> implications that I need to be aware of. >> >> If you just change the initial value in target.c, it won't do what you >> need because currently, if you compile sparse on a machine where >> __x86_64__ is defined, it will automatically enable the -m64 option >> which will setup things for an LP64 architecture instead of the LLP64 >> that you need (inside handle_arch_m64_finalize()). >> > > Yes I noticed that and I can easily make that conditional on MSVC. I > guess my question is more whether there are any assumptions in the > code that a long in a 64-bit environment is 64-bits (e.g. pointers fit > into long). I have not yet been able to run all the tests on Windows, > but I guess that is one way I can find out if there are any issues. There shouldn't be any such assumptions :) And I think, you shouldn't have much bad surprised, but I'm a bit less confident regarding the test-suite. It's very possible that some tests have the assumption that sizeof(long) == sizeof(pointer). And I'm pretty sure that this LLP64 situation have been very little tested, very possibly never been tested at all. Luc -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
