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

[Eli Zaretskii <eliz@gnu.org>]

> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Sun, 08 Oct 2017 23:04:10 +0000
> Cc: emacs-devel@gnu.org
> 
>  If we were to change make_specified_string (and its subroutines, like
>  make_uninit_multibyte_string etc.) to accept a size_t value in its 3rd
>  argument, the need for the above check against PTRDIFF_MAX would
>  disappear.
> 
> It wouldn't disappear, it would merely be shifted around. Arguments could be made for either choice, but
> somewhere the check needs to happen.

No, the need will entirely disappear, because
make_uninit_multibyte_string already has a similar check, it just uses
signed types for it currently.

>  It would also make the higher-level code more
>  reliable, because application-level programmers will not need to
>  understand all the non-trivial intricacies of this stuff. 
> 
> Every C programmer needs to understand these issues, no matter what codebase they are working with.

I agree that it's very useful to understand these issues, but by
requiring "every C programmer" to understand them, you are raising the
bar for contributing to Emacs's C code considerably and IMO without
any good reason.  A C programmer for Emacs who needs to use primitives
that create Lisp objects should expect those primitives to be safe,
just like you expect libc function to be safe, once they pass the
compilation with -Wall.

> Lossy integral conversions are fundamental design choices of the C language that can't be avoided. 

They can and should be avoided on the level of jason.c, as long as the
code itself doesn't do anything silly, which will then be flagged by
the compiler.

> C is a nasty language full of traps.

I certainly disagree with that, having programmed in C for 35 years.

> You can try to hide some of the traps, but you can't remove them.

I want to hide them, as much as possible, from application-level code.