> Cc: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org > From: Stefan Monnier <[EMAIL PROTECTED]> > Date: Mon, 11 Dec 2006 23:48:43 -0500 > > > Is it really that smart? Will it also be that smart if we do some > > arithmetics, like `(EMACS_INT)i + 0L' or `(EMACS_INT)i*1L'? > > Could be, or maybe not. My guess is that the optimization scheme uses an > abstract domain where integer values are approximated by bounds (so a char > is approximated by [-128..127]), so "+1" should be handled just fine (after > conversion to EMACS_INT this same char is still [-128..127] and since "1" > is most likely approximated by [1..1], then the sum of the two will be > approximated by [-127..128]). > > But why should it matter whether it does or not?
Because if we understand that, we could devise a way to defeat the warning. > I agree with the intention but I wouldn't want to "fix" the warnings by > applying the optimization by hand, unless the code after optimization is > just as clean and maintainable. I don't see how it can be less maintainable than it is now, what with the multi-layered macros we sprinkle everywhere. _______________________________________________ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
