From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: oops? read/write vs type of length parameter Date: Mon, 11 Apr 2011 13:28:51 +0200 Organization: Organization?!? Message-ID: <87bp0dm3gs.fsf@fencepost.gnu.org> References: <87wrj1jhfc.fsf@rho.meyering.net> <87d3ktjb9l.fsf@rho.meyering.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1302521359 24163 80.91.229.12 (11 Apr 2011 11:29:19 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 11 Apr 2011 11:29:19 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 11 13:29:15 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Q9FIv-0007h3-N8 for ged-emacs-devel@m.gmane.org; Mon, 11 Apr 2011 13:29:14 +0200 Original-Received: from localhost ([127.0.0.1]:52420 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q9FIt-0004cP-Rb for ged-emacs-devel@m.gmane.org; Mon, 11 Apr 2011 07:29:11 -0400 Original-Received: from [140.186.70.92] (port=50944 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q9FIo-0004bU-0a for emacs-devel@gnu.org; Mon, 11 Apr 2011 07:29:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q9FIm-0004Ql-9j for emacs-devel@gnu.org; Mon, 11 Apr 2011 07:29:05 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:53392) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q9FIl-0004QY-T1 for emacs-devel@gnu.org; Mon, 11 Apr 2011 07:29:04 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Q9FIk-0007c6-B8 for emacs-devel@gnu.org; Mon, 11 Apr 2011 13:29:02 +0200 Original-Received: from p508ecc97.dip.t-dialin.net ([80.142.204.151]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 11 Apr 2011 13:29:02 +0200 Original-Received: from dak by p508ecc97.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 11 Apr 2011 13:29:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 37 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: p508ecc97.dip.t-dialin.net X-Face: 2FEFf>]>q>2iw=B6, xrUubRI>pR&Ml9=ao@P@i)L:\urd*t9M~y1^:+Y]'C0~{mAl`oQuAl \!3KEIp?*w`|bL5qr,H)LFO6Q=qx~iH4DN; i"; /yuIsqbLLCh/!U#X[S~(5eZ41to5f%E@'ELIi$t^ Vc\LWP@J5p^rst0+('>Er0=^1{]M9!p?&:\z]|;&=NP3AhB!B_bi^]Pfkw User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:Q5CO83nBgLkVNFGlUBE5qvP25zA= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 80.91.229.12 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:138382 Archived-At: Jim Meyering writes: > Currently, emacs_write silently ignores an invalid buffer length, > treating it just like a length of 0. It'd be better not to ignore > such an error. > > IMHO, an interface that takes a logically unsigned parameter > should have an unsigned type. In that case, there _are_ no invalid buffer lengths since any invalid length is turned into a humongous valid one. Since the starting value is from EMACS_INT... > I guess I'm biased towards least-surprise for developers, so I think > read- and write-like functions should accept a buffer length argument > of type size_t, to be consistent with read and write. I prefer surprise while reading the prototypes to surprise while actually calling the function. A reinterpretation of signed numbers into the unsigned realm is not going to cause much joy here. > To try to protect against bugs by changing API to a signed type may > actually cause trouble when callers end up mixing/comparing their > newly signed (to accommodate the invented API) and unsigned lengths > from standard functions. In C, (-1 > 10U) is true. In practice, unsigned types cause much more trouble and confusion than they avoid. > Another thing to keep in mind: on some older systems, trying to read > more than INT_MAX bytes in a single syscall will fail. Are you trying to argue for or against your proposal? -- David Kastrup