[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 27 Jun 2013 12:35:22 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: Use of size_t and ssize_t in mseek
* Rich Felker <dalias@...ifal.cx> [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);
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.
