[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130627150548.GY29800@brightrain.aerifal.cx>
Date: Thu, 27 Jun 2013 11:05:48 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Use of size_t and ssize_t in mseek
On Thu, Jun 27, 2013 at 12:35:22PM +0200, Szabolcs Nagy wrote:
> * 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);
Using sbrk alongside anything else in the standard library invokes
horrible UB, so I don't really care about sbrk.
> 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)
There's not a constraint, but the compiler is providing a low quality
of implementation if it allows them, since its ptrdiff_t is too small
to work with them.
> 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);
Formally these should probably be thought of as two objects where the
address of the element one past the end of the first happens to be
equal to the address of the second (which the C language allows). Of
course I agree it could be argued both ways. However, either way, this
kind of thing is sufficiently intentional and fragile that someone
doing it would expect breakage, I think. What I'm concerned about is
the possibility that someone could inadvertently obtain such an
object, e.g. via passing a size obtained from a file or from the
network to malloc, etc. But thanks for the thorough consideration of
the issue. :-)
Rich
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.
