lucene-pylucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andi Vajda <va...@apache.org>
Subject Re: python 3 support is checked into trunk
Date Mon, 20 Mar 2017 17:29:39 GMT

On Mon, 20 Mar 2017, Andi Vajda wrote:

>
>> On Mar 20, 2017, at 10:12, Ruediger Meier <sweet_f_a@gmx.de> wrote:
>>
>> On Monday 20 March 2017, Andi Vajda wrote:
>>>>> On Mar 20, 2017, at 05:16, Ruediger Meier <sweet_f_a@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
>
>

Mime
View raw message