Re: JSON/YAML/TOML/etc. parsing performance

[Paul Eggert]

On 10/06/2017 12:40 AM, Eli Zaretskii wrote:
> Those valid-but-enormous values are either invalid (if they are larger
> than PTRDIFF_MAX), or easily uncovered by looking at higher call-stack
> frames in the debugger
I'm not quite following, since "valid-but-enormous values" cannot be 
invalid. However, I don't normally use a debugger to find or debug 
integer-overflow problems. I more often use static analysis, for which 
signed integers work better since static analysis can more-easily detect 
signed operations that look dubious. When I do run-time checking, I 
normally use -fsanitize=undefined or something like that, instead of 
GDB; and here again, signed integers work better than unsigned integers do.

> I don't envision many primitives to need this kind of change
At present zero primitives need this kind of change for JSON, since the 
JSON code doesn't need to do any overflow checking for sizes under the 
currently-proposed patches. If we run across the problem in the future 
for other libraries, we can revisit the issue then.

> I'm not sure that experience is 100% applicable to Emacs, because
> Emacs has special needs due to the fact that our integers are narrower
> than the corresponding C integral types.
That problem is separate from the ptrdiff_t vs size_t problem, which is 
the issue at hand here, and which corresponds directly to the experience 
I've had with with ptrdiff_t and size_t in other GNU programs. 
Preferring ptrdiff_t to size_t (or vice versa) does not affect whether 
code needs to check for fixnum overflow.