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

[Eli Zaretskii]

> Cc: address@hidden, address@hidden
> From: Paul Eggert <address@hidden>
> Date: Wed, 4 Oct 2017 10:51:33 -0700
> 
> We should not encourage more use of size_t within Emacs, as it's an 
> unsigned type and unsigned types have the problems I mentioned.

But if we did use size_t for the arguments which can clearly only be
non-negative, the problems which we are discussing would not have
happened, and we could simply rely on our primitives to do those
checks.  So it sounds like by avoiding use of size_t in those cases,
we are shooting ourselves in the foot, by making our code more
complex, less readable, and less efficient.  IOW, a net loss.  Look
how much more complex is the proposed code in json.c than it could
have been: we could remove all the redundant checks and quite some
code that supports them.

So I'm questioning the total avoidance of size_t in our low-level
code.  Why not allow it in a few places where negative values are
clearly mistakes/bugs, and so if they appear as large positive values,
and are rejected as such, that's OK?