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. 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. %jx/PRIxMAX is the biggest possible for uintmax_t. cu, Rudi
