> On Mar 20, 2017, at 10:12, Ruediger Meier <sweet_...@gmx.de> wrote: > > On Monday 20 March 2017, Andi Vajda wrote: >>>> On Mar 20, 2017, at 05:16, Ruediger Meier <sweet_...@gmx.de> wrote: >>>> On Monday 20 March 2017, Andi Vajda wrote: >>>> >>>> On Mon, 20 Mar 2017, Ruediger Meier wrote: >>>>>> Someone with access to Windows, please help test/fix/finish >>>>>> support for Python 3 on Windows, both with the MSVC and Mingw >>>>>> compilers. I have no access to Windows anymore. >>>>> >>>>> I know already about one MSVC issue: >>>>> https://github.com/rudimeier/jcc/issues/1 >>>>> >>>>> probably fixed by >>>>> https://github.com/rudimeier/jcc/commit/764ed0dc1f77c68e4a6998688 >>>>> d2 e8340704fd237 (But this fix is also not tested yet.) >>>> >>>> I changed strhash to use Py_hash_t. >>> >>> This is now wrong and I could reproduce a segfault on OSX 10.11, >>> xcode 8. The buffersize "hexdig + 1" has to match the type we are >>> printing. We can't calculate the size from Py_hash_t but print >>> ulong. >> >> Ah yes, good point. Sorry for the mess up. >> >>> Most safely and without precision loss we could do it like the >>> patch below. >>> >>> Notes: >>> 1. "static const" was required to actually fix MSVC's VLA issue. >> >> Yes, but that's not reentrant, thus we need to switch back to a >> constant size for the array, like [20] we ad before, or [40] now. > > Not reentrant? static const should be as good as a #define IMO.
Ah you mean static const for the size, not for the array. That would work. > In doubt > you could avoid the variable and use "sizeof(hash) * 2" two times > where we need it. > >>> 2. The macro PRIxMAX is the same as "%jx". I've choosed the macro >>> because it should be compatible to Visual Studio >=2013 while "%jx" >>> would need Visual Studio >=2015. Moreover when using incompatible >>> compilers the macro would give an error at compile time rather >>> than "%jx" would just crash at runtime. >> >> What's wring with %lx ? > > %lx is for long but Py_hash_t can be longer. Can it ? Py_hash_t is defined to be the same as Py_ssize_t. What's its size ? > %jx/PRIxMAX is the biggest > possible for uintmax_t. Is that bigger than unsigned long ? Ok, I think the time has come to see if this function can be removed altogether... let me see... Andi.. > > cu, > Rudi
