[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?
Re: JSON/YAML/TOML/etc. parsing performance, Paul Eggert, 2017/10/03
- Re: JSON/YAML/TOML/etc. parsing performance, Eli Zaretskii, 2017/10/04
- Re: JSON/YAML/TOML/etc. parsing performance, Paul Eggert, 2017/10/04
- Re: JSON/YAML/TOML/etc. parsing performance,
Eli Zaretskii <=
- Re: JSON/YAML/TOML/etc. parsing performance, Paul Eggert, 2017/10/04
- Re: JSON/YAML/TOML/etc. parsing performance, Eli Zaretskii, 2017/10/04
- Re: JSON/YAML/TOML/etc. parsing performance, Paul Eggert, 2017/10/04
- Re: JSON/YAML/TOML/etc. parsing performance, Paul Eggert, 2017/10/04
- Re: JSON/YAML/TOML/etc. parsing performance, Eli Zaretskii, 2017/10/05
- Re: JSON/YAML/TOML/etc. parsing performance, Philipp Stephani, 2017/10/08
- Re: JSON/YAML/TOML/etc. parsing performance, Paul Eggert, 2017/10/09
- Re: JSON/YAML/TOML/etc. parsing performance, Philipp Stephani, 2017/10/29
Re: JSON/YAML/TOML/etc. parsing performance, Eli Zaretskii, 2017/10/09
Re: JSON/YAML/TOML/etc. parsing performance, Eli Zaretskii, 2017/10/05