Hal Murray :
> > I'm divided in my mind about whether to fix this. It's not really right,
> > ...
>
> Do we have a good place to document it?
The internals tour, maybe.
> It's possible that the Bison parser does range checks and doesn't allow the
> nasty case.
It doesn't. I know that code q
> I'm divided in my mind about whether to fix this. It's not really right, ...
Do we have a good place to document it?
It's possible that the Bison parser does range checks and doesn't allow the
nasty case.
--
These are my opinions. I hate spam.
__
Hal Murray :
> I don't see any simple fix. I assume the clean fix is to add T_Unsigned.
Yes, I think so.
I'm divided in my mind about whether to fix this. It's not really right, but
adding the extra complexity wouldn't necessarily buy us anything either. It's
quite unlikely the problem case wil
>> Unless I missed something, the code processing gonfig slots can't
distinguish
>> -1 from 0x or the equivalent decimal number.
...
> That is correct. Is this leading to a bug?
I don't know of a case where it currently causes problems. We might be able
to find one if we look hard eno
Hal Murray via devel :
>
> Unless I missed something, the code processing gonfig slots can't distinguish
> -1 from 0x or the equivalent decimal number.
> They both come through as T_Integer. There is no T_Unsigned
>
> The checking code gets to pull it as either xx->val.i or xx->val.u
>
Unless I missed something, the code processing gonfig slots can't distinguish
-1 from 0x or the equivalent decimal number.
They both come through as T_Integer. There is no T_Unsigned
The checking code gets to pull it as either xx->val.i or xx->val.u
struct attr_val_tag {
attr_va
