Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 27 Jun 2013 12:35:22 +0200
From: Szabolcs Nagy <>
Subject: Re: Use of size_t and ssize_t in mseek

* 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);


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);

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.