From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Chong Yidong Newsgroups: gmane.emacs.devel Subject: image size limit? Date: Tue, 11 Oct 2005 16:32:50 -0400 Message-ID: <87oe5v7q19.fsf@stupidchicken.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1129062921 15632 80.91.229.2 (11 Oct 2005 20:35:21 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 11 Oct 2005 20:35:21 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 11 22:35:18 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EPQo7-0004lS-EX for ged-emacs-devel@m.gmane.org; Tue, 11 Oct 2005 22:33:07 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EPQo6-00068M-QQ for ged-emacs-devel@m.gmane.org; Tue, 11 Oct 2005 16:33:06 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EPQnx-00066M-PK for emacs-devel@gnu.org; Tue, 11 Oct 2005 16:32:57 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EPQnw-00066A-9R for emacs-devel@gnu.org; Tue, 11 Oct 2005 16:32:57 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EPQnw-000667-4J for emacs-devel@gnu.org; Tue, 11 Oct 2005 16:32:56 -0400 Original-Received: from [18.95.6.216] (helo=localhost.localdomain) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EPQnw-00010Z-9P for emacs-devel@gnu.org; Tue, 11 Oct 2005 16:32:56 -0400 Original-Received: by localhost.localdomain (Postfix, from userid 1000) id 98C791E4448; Tue, 11 Oct 2005 16:32:50 -0400 (EDT) Original-To: emacs-devel@gnu.org User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) 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:43886 Archived-At: Can we get this discussion going again? From FOR-RELEASE: Put a max-limit on the size of images, e.g. based on the display size. This is to avoid allocating insane amounts of memory due to bogus image size specifications. Note: rather than clipping images that are too big (this may be non-trivial to do correctly in all cases -- and thus non-trivial to test), it may be better just to avoid displaying such images for emacs 22. I am not an expert, but from looking through image.c, it seems that there is only so much we can do to prevent memory over-allocation problems. Generally, we have to call an external library to load an image file, which does its own memory management thing. By the time we know the width and height, the external library has already loaded the file into memory (or signalled an error). For example, gif_load looks something like this: gif = (GifFileType *)fn_DGifOpenFileName (SDATA (file)); .... /* Read entire contents. */ rc = fn_DGifSlurp (gif); ... image_top = gif->SavedImages[ino].ImageDesc.Top; ... x_create_x_image_and_pixmap (f, width, height, ...); We have no control over what DGifSlurp does. One place where we can set a limit is in x_create_x_image_and_pixmap, where we malloc a pixmap to store the image contents. The data supplied to us by the external library is copied into this pixmap. We could signal an error if width and height are too large. However, this seems like closing the barn door after the horses have left -- the external library will already have allocated a big chunk of memory. Thoughts?