On Mon, Jul 28, 2014 at 11:15 AM, Stefan Behnel <stefan...@behnel.de> wrote:
> Robert Bradshaw, 15.07.2014 23:13: > > On Mon, Jul 14, 2014 at 12:49 PM, Stefan Behnel wrote: > >> by applying some initially small but perpetually growing fixes, I pushed > >> myself into a corner where the only escape was to rewrite BoolBinopNode > >> (short-circuiting and/or expressions). This was long overdue anyway and > >> simply wasn't done before because it's not trivial and quite risky. I > think > >> I got it working better than before, but there are still corner cases > that > >> require some further fighting. One of them currently crashes the pyregr > >> tests in Py2.7 [...] > > > > Ironically, I noticed these BoolBinop failures and started working on a > fix > > myself (including side diversions like making void* the spanning type of > > all pointers) before noticing that you were on it, so I have a bit of an > > idea what a long, twisty path this starts down and can only say thanks > for > > taking this on. > > It looks like I got all corner cases fixed that I could find anywhere on > Jenkins (and I definitely broke enough builds along the way). That brings > master back to a state where I think we should plan for an alpha release to > get testing on user side as well. Sound good. There's a lot of stuff in this release. > Regarding the void* spanning type, it's currently only used for > independently inferred types for the operands of conditional and and/or > expressions. I don't see a reason not to enable it for all type inference > cases, though. Any objections to that? > The other case I could see it coming up is common = some_int_ptr() common = some_double_ptr() Which formerly would be an error. The C standard prohibits pointer arithmetic with void*, but gcc accepts it (as if it were a char* IIRC). However, it can't be dereferenced without casting to another pointer type, so it's not totally unsafe. I think it's OK to enable everywhere, making things more consistent. - Robert
_______________________________________________ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel