From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: oops? read/write vs type of length parameter Date: Thu, 14 Apr 2011 22:29:22 -0300 Message-ID: References: <87wrj1jhfc.fsf@rho.meyering.net> <87hba5yq0p.fsf@uwakimon.sk.tsukuba.ac.jp> <834o64sxd7.fsf@gnu.org> <4DA3A7F8.1020503@cs.ucla.edu> <83k4f0qijz.fsf@gnu.org> <4DA3DDCD.10700@cs.ucla.edu> <4DA40AFE.8050406@cs.ucla.edu> <4DA47581.9010509@cs.ucla.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1302833243 15862 80.91.229.12 (15 Apr 2011 02:07:23 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 15 Apr 2011 02:07:23 +0000 (UTC) Cc: Eli Zaretskii , jim@meyering.net, emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 15 04:07:19 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QAYRE-0006Ei-6A for ged-emacs-devel@m.gmane.org; Fri, 15 Apr 2011 04:07:12 +0200 Original-Received: from localhost ([::1]:44704 helo=lists2.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QAYRD-00086z-Mj for ged-emacs-devel@m.gmane.org; Thu, 14 Apr 2011 22:07:11 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:43923) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QAYQs-0007Wb-Qy for emacs-devel@gnu.org; Thu, 14 Apr 2011 22:06:52 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QAYQs-00065K-2N for emacs-devel@gnu.org; Thu, 14 Apr 2011 22:06:50 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]:44580) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QAYQr-00065B-Vz for emacs-devel@gnu.org; Thu, 14 Apr 2011 22:06:50 -0400 Original-Received: from 213-159-126-200.fibertel.com.ar ([200.126.159.213]:45884 helo=ceviche.home) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1QAYQq-0003zX-9X; Thu, 14 Apr 2011 22:06:48 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id AA6DD665EC; Thu, 14 Apr 2011 23:06:45 -0300 (ART) In-Reply-To: <4DA47581.9010509@cs.ucla.edu> (Paul Eggert's message of "Tue, 12 Apr 2011 08:53:37 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.10 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:138492 Archived-At: > If the code is well-defended against passing negative sizes, > then we can remove the checks entirely; they're not needed. > They were meant only as a stopgap in case the callers were > buggy. (Also please see below.) The old approach of being somewhat permissive worked well for decades, I see no reason to change it. > Any compiler that will warn about conversions to size_t will > warn about hundreds of other places in Emacs. These warnings > are more trouble than they're worth, and we shouldn't worry > about them. I hate casts and generally hate unsigned integers as well, so please don't introduce changes that add uses of casts or unsigned integers unless absolutely necessary. >>> with the goal of removing the runtime checks once we have >>> carefully checked that they aren't needed. >> Which will never happen, so these aborts will stay in the code >> forever. > I can do it, in the next day or two. It shouldn't be a problem. That's not how it works: Emacs will keep being changed in the future. > I'm sorry if there are hurt feelings about this, but size_t is > clearly the better choice for buffer sizes; No, it's not. Maybe it's your favorite and it probably is the standard in the C API, but that doesn't make it "clearly the better choice". E.g. it's a choice I strongly dislike. The only cases where I like to use unsigned integers is when we treat them as bitvectors, all other cases end up creating errors because they eventually meet with signed types introducing unexpected behaviors. This is particularly true in the context of Emacs where most/many integer values go through Elisp where they are always signed. Stefan