Re: Possible infinite loop in qsort()

[Rich Felker <dalias@libc.org>]

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