Re: Weird parsing error in Pike 8.1

And grubba was faster than me. My solution was a bit different, it just
sets the type to 'tInt' if either of the min/max values does not fit
into INT32. I believe that is more correct.

arne

diff --git a/lib/modules/Tools.pmod/Standalone.pmod/precompile.pike
b/lib/modules/Tools.pmod/Standalone.pmod/precompile.pike
index 0a58823..05ca96f 100644
--- a/lib/modules/Tools.pmod/Standalone.pmod/precompile.pike
+++ b/lib/modules/Tools.pmod/Standalone.pmod/precompile.pike
@@ -821,12 +821,26 @@ class PikeType
        case "program": return "tPrg(tObj)";
        case "any":     return "tAny";
        case "mixed":   return "tMix";
-       case "int":
+       case "int": {
          // NOTE! This piece of code KNOWS that PIKE_T_INT is 8!
-         return stringify(sprintf("\010%4c%4c",
-                                  (int)(string)(args[0]->t),
-                                  (int)(string)(args[1]->t)));
+          int min = (int)(string)(args[0]->t);
+          int max = (int)(string)(args[1]->t);
+
+          if (min > max) error("Minimum > Maximum in int type.\n");
+
+          if (max < -0x80000000 || max > 0x7fffffff) {
+            warn("Maximum %d does not fit into INT32.\n", max);
+            return "tInt";
+          }

+          if (min < -0x80000000 || min > 0x7fffffff) {
+            warn("Maximum %d does not fit into INT32.\n", max);
+            return "tInt";
+          }
+
+         return stringify(sprintf("\010%4c%4c", min, max));
+
+        }
        case "bignum":
        case "longest":
          return "tInt";



On 11/20/14 13:18, Arne Goedeke wrote:
> 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.
>>
>