Re: Weird parsing error in Pike 8.1

The type of read_int32 is broken, because the min max values end up
being min=0 and max=-1. The max value is MAX_UINT32, which does not fit
into INT32 and ends up being -1.
Even in debug mode this is not caught, because (for some reason) the
debug check in push_int_type does only check for min < max if they have
the same sign (anyone can explain why?).
I will commit a fix to precompile.pike which prevents that. Not sure if
that fixes your problem, though.

arne

On 11/20/14 10:05, Stephen R. van den Berg wrote:
> Stephen R. van den Berg wrote:
>> Chris Angelico wrote:
>>> 22dbe6 - there was a typo in an apparently-unrelated piece of code,
> 
>>> in its own compilation error. But with that fixed, reverting c7de86
>>> doesn't reinstate the behaviour you referred to. Is that any sort of
>>> clue? It doesn't say anything to my mind.
> 
> With regards to apparently-unrelated and clue, yes, this is a clue, but
> it points (AFAICS) towards some obscure stuff which is either
> not right in the perceived declaration of the Stdio.Buffer.read_int32
> member, or a parser in Pike running on steroids mixing up ints and
> voids under the right stellar constellations.
>