From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9112 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Possible infinite loop in qsort() Date: Thu, 14 Jan 2016 17:21:51 -0500 Message-ID: <20160114222151.GU238@brightrain.aerifal.cx> References: <20160109082139.GD2016@debian> <20160109090719.GA385@nyan> <20160110040516.GQ238@brightrain.aerifal.cx> <20160110113852.GE2016@debian> <5694F0D5.8080709@openwall.com> <20160112124855.GB13558@port70.net> <56950E43.60508@openwall.com> <20160112162243.GC13558@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1452810130 8701 80.91.229.3 (14 Jan 2016 22:22:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 14 Jan 2016 22:22:10 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9125-gllmg-musl=m.gmane.org@lists.openwall.com Thu Jan 14 23:22:09 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1aJqHN-0005wr-Fk for gllmg-musl@m.gmane.org; Thu, 14 Jan 2016 23:22:05 +0100 Original-Received: (qmail 7423 invoked by uid 550); 14 Jan 2016 22:22:04 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 7401 invoked from network); 14 Jan 2016 22:22:03 -0000 Content-Disposition: inline In-Reply-To: <20160112162243.GC13558@port70.net> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:9112 Archived-At: On Tue, Jan 12, 2016 at 05:22:44PM +0100, Szabolcs Nagy wrote: > > >i think if an implementation does not give this guarantee > > >that should be considered a bug. > > > > Some consider it a bug, others -- a feature. > > > > But if you want to provide this guarantee it's not that easy. Compilers are > > not under your control. Even with gcc (which tries to provide this > > guarantee) you can create VLA 2.5GB in size and run it with `ulimit -s > > unlimited` (at least as a 32-bit binary on a 64-bit host). > > > > large vla sounds like a problem, the libc can guard against that > by placing a guard page in the way on the main thread. > > but stack allocations are kind of outside the c language: > stack limits are not admitted in the standard causing technical > issues around correctness proofs. While the C standard fails to specify it as such, overflowing the stack has to be treated as undefined behavior. One such case of overflow is an object >SIZE_MAX/2 bytes. > > Then, a user can create an object of any size via mmap with MAP_FIXED flag, > > right? > > creating a single object by two mmaps that happen to be > adjacent sounds like a grey area (not sure if that's strictly > conforming in posix/c). POSIX is not clear on how the memory obtained by mmap becomes C "objects", but it's not important anyway. You cannot use MAP_FIXED to create such objects because passing an address to mmap/MAP_FIXED that you don't already own/control produces UB. You could use opportunistic address requests to attempt to produce such a large contiguous region, but you still would not be justified in interpreting them as a single large object. > the user can get a large object behind the libc (e.g. by using > raw syscalls) but the portable ways are controlled by the libc. These are not formal objects; if you do stupid stuff by calling syscalls directly, you get what you deserve. Rich