On Tuesday 25 October 2011 10:43:38 Cactus wrote: > The issue of 32/64-bit integers on Windows comes up regularly and, after > the recent discussion, I have been wondering if there is a > relatively easy implementation strategy. > > Since we already know from 64-bit Unix/Linux distributions that the > existing *_ui and *_si functions work when signed and unsigned integers > are 64 bit long, could we not: > > (a) define two _new_ integer types for signed and unsigned integers > (b) use these for _both_ the interfaces and internally in all *_ui and > *_si functions > (c) normally define these types as signed and unsigned integers > (d) but allow alternative definitions, for example, using 64-bit types on > Windows x64 > > We would need to check out all the ui/si function code for oddball cases > but my guess is that a lot of it would work without changes. > > This would not only cover the Windows problem but would also allow these > defines to be set to intmax_t and uintmax_t where this was advantageous. > > It would also avoid a lot of new code where, for example, we duplicate all > existing ui/si functions but with 64-bit integers (which seems to me very > messy since we end up with a lot more code to test and maintain) > > Would this work? Would there be unintended consequences? > > If it's a stupid idea just say so!
Sounds good and simple , the only possible drawback is weird things like this from gmp-in.h /* __GMP_USHRT_MAX is not "~ (unsigned short) 0" because short is promoted to int by "~". */ #define __GMP_UINT_MAX (~ (unsigned) 0) #define __GMP_ULONG_MAX (~ (unsigned long) 0) #define __GMP_USHRT_MAX ((unsigned short) ~0) although the integer type are always? promoted to bigger not smaller types Jason -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
