Eli Zaretskii <address@hidden
> schrieb am Di., 3. Okt. 2017 um 19:10 Uhr:
> Date: Tue, 03 Oct 2017 19:26:53 +0300
> From: Eli Zaretskii <address@hidden>
> Cc: address@hidden
> > I don't understand why you think these checks aren't necessary. Converting
> > between integral types when the number is out of range for the destination
> > type results in an implementation-defined result, i.e. it's unportable.
> I'm saying that this code is the wrong place for doing these checks.
> We can discuss whether these checks are needed in general, and if we
> agree they are, we should change all the related allocation
> subroutines to do that there.
Let me say this another way: Paul Eggert and others have spent the
last several years hardening Emacs primitives for all kinds of
infrequent situations where we could have undefined behavior. We now
have in many places dozens of tests and tricky macros we never had
before with checks and defenses against such calamities. If, after
all that, we still need application-level C code to do its own checks
for such situations, then I don't understand what we were doing all
these years, and why all the safety nets we added are not good enough
for taking care of this code as well.
I'm certain those changes are useful! But they can't protect from data loss due to lossy type conversions; that is just a general behavior of C, and all C code needs to deal with it.