From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3472 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: Use of size_t and ssize_t in mseek Date: Thu, 27 Jun 2013 12:35:22 +0200 Message-ID: <20130627103521.GG15323@port70.net> References: <51CBB6E1.6080302@nicta.com.au> <20130627041028.GV29800@brightrain.aerifal.cx> <51CBBC8F.5050301@nicta.com.au> <20130627042314.GW29800@brightrain.aerifal.cx> 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 1372329336 25931 80.91.229.3 (27 Jun 2013 10:35:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 27 Jun 2013 10:35:36 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3476-gllmg-musl=m.gmane.org@lists.openwall.com Thu Jun 27 12:35:38 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Us9Y9-0000Wi-5R for gllmg-musl@plane.gmane.org; Thu, 27 Jun 2013 12:35:37 +0200 Original-Received: (qmail 13940 invoked by uid 550); 27 Jun 2013 10:35:34 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 13931 invoked from network); 27 Jun 2013 10:35:34 -0000 Content-Disposition: inline In-Reply-To: <20130627042314.GW29800@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3472 Archived-At: * Rich Felker [2013-06-27 00:23:14 -0400]: > some reasonable error, but I still want to find and fix any remaining > places where objects larger than PTRDIFF_MAX could come into existence > since they affect other code too, and once those are fixed, the check > in fmemopen would be obsolete. > > As far as I can tell, mmap and maybe shmat are the only functions that > might be able to make such large objects. Do you know any others? void *p=sbrk(1<<30); sbrk(1<<30); or int main() { char a[1U<<31]; } it seems compilers dont like objects >=2G size either (is there a constraint for this in the standard? gcc even fails if the sum of the local objects are >=2G, but tcc, pcc generates code in that case) i assume isoc would not allow this but you can concatenate address ranges: char *p,*q; q = mmap(0, 1<<30, prot, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0); p = mmap(q-(1<<30), 1<<30, prot, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0); if (p && q && p == q-(1<<30)) { now p points to a 2G continous address range you could even mprotect(p, 1U<<31, prot);