[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eli Zaretskii
Subject: Re: JSON/YAML/TOML/etc. parsing performance
Date: Wed, 04 Oct 2017 11:03:53 +0300

> Cc: address@hidden, address@hidden
> From: Paul Eggert <address@hidden>
> Date: Tue, 3 Oct 2017 23:41:41 -0700
> Eli Zaretskii wrote:
> > I'd prefer to have such tests inside 'insert' and its subroutines, or
> > to tweak the argument passed to 'insert' to have the existing checks
> > catch the problem.  Can we do that, please?  It doesn't feel right to
> > me to have this kind of checks in application C code.
> There is no universal C integer type, so this doesn't sound doable in 
> general. 
> Even intmax_t is not wide enough, as it doesn't subsume uintmax_t. And I 
> wouldn't want APIs to switch to intmax_t or uintmax_t merely because some 
> library's types don't match ours; the responsibility for passing arguments 
> correctly and for checking for any out-of-range values belongs to the glue 
> code, 
> not to Emacs internals.

That sounds very uncool, since many libraries use size_t, which means
we will have to spread these checks for extremely rare cases all over
our code, thus making it harder to read and maintain, and making it
slower for no good reason.

E.g., I see several uses of size_t in gnutls.c and in image.c, and at
least some of them seem to be of the same nature as what was discussed
here.  Why didn't we add similar checks there?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]