On Mon, 20 Mar 2017, Andi Vajda wrote:
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...
Ah, no, this is used quite a bit. It's got to stay and work.
Andi..
Andi..
cu,
Rudi
