Eli Zaretskii schrieb am Di., 3. Okt. 2017 um 19:10 Uhr: > > Date: Tue, 03 Oct 2017 19:26:53 +0300 > > From: Eli Zaretskii > > Cc: emacs-devel@gnu.org > > > > > 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.