From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Philipp Stephani
> Cc: p.st= ephani2@gmail.com, emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Wed, 4 Oct 2017 14:24:59 -0700
>
> On 10/04/2017 12:38 PM, Eli Zaretskii wrote:
> > if we did use size_t for the arguments which can clearly only be<= br> > > non-negative, the problems which we are discussing would not have=
> > happened
> Sure, but we would also have worse problems, as size_t is inherently > more error-prone. ptrdiff_t overflows are reliably diagnosed when Emac= s
> is compiled with suitable GCC compiler options. size_t overflows canno= t
> be diagnosed, are all too common, and can cause serious trouble.
If ptrdiff_t overflows are reliably diagnosed, then why do we have to
test for them explicitly in our code, as in the proposed json.c?
AFAIU, ptrdiff_t overflows are the _only_ reason for json.c checks
whether a size_t value is too large, because similar checks for
ptrdiff_t values are already in the low-level subroutines involved in
creating Lisp objects.=C2=A0 So why couldn't those checks be avoided by=
simply assigning to a ptrdiff_t variables?
> The Emacs internals occasionally use size_t because underlying
> primitives like 'malloc' do, so we do make some exceptions. Pe= rhaps
> there should be an exception here, for convenience with the JSON
> library. The code snippets I've seen so far in this thread are not=
> enough context to judge whether an exception would be helpful in this<= br> > case. Generally speaking, though, unsigned types should be avoided
> because they are more error-prone. This has long been the style in Ema= cs
> internals, and it's served us well.
I'm not arguing for general replacement of ptrdiff_t with size_t, only<= br> for doing that in those primitives where negative values are a clear
mistake/bug.
For example, let's take this case from your proposed changes:
=C2=A0 =C2=A0static Lisp_Object
=C2=A0 -json_make_string (const char *data, ptrdiff_t size)
=C2=A0 +json_make_string (const char *data, size_t size)
=C2=A0 =C2=A0{
=C2=A0 +=C2=A0 if (PTRDIFF_MAX < size)
=C2=A0 +=C2=A0 =C2=A0 string_overflow ();
=C2=A0 =C2=A0 =C2=A0return make_specified_string (data, -1, size, true);
=C2=A0 =C2=A0}
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.
=C2=A0 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.=C2=A0