> Sorry, but then I must be the one that is blind.

Nah, i might be; that's what i get for staying up for too long...  8-)

> I cannot see that the manual entry documents any result of calling sbrk
> with an argument different from 0. If this is the intention (in order to
> deprecate use of sbrk with other arguments), IMHO this should be more clearly
> stated.

to quote:

RETURN VALUES
     Brk returns a pointer to the new end of memory if successful; otherwise
     -1 with errno set to indicate why the allocation failed.  The sbrk func-
     tion returns a pointer to the base of the new storage if successful; oth-
     erwise -1 with errno set to indicate why the allocation failed.

I guess it _doesn't_ explicitly say how much new storage is allocated,
or where.  Perhaps it should be more clearly documented.  on the other
hand, it also makes sense that it should be intentionally vague,
esp. given the initial comment in the manual page.  basically "these
functions may be implemented differently than you're used to, in the
future."

> BTW, I don't understand the wording in "Data addressing is restricted between
> addr and the lowest stack pointer to the stack segment." What does lowest
> refer to? And what is the stack segment?

Your stack starts somewhere.  it has a maximum size.  you can't set
the 'break' to be anywhere in that region.

> Note that even if I interpret it
> according to my a posteriori knowledge of the semantics of U*X systems, it
> is wrong anyway, since there might be mmap'ed data in this area.

quite right.  that's the point, i think of the:

The brk and sbrk functions are historical curiosities left over from ear-
lier days before the advent of virtual memory management.

comment in the man page...

They could go away, and are only used for historical compatibility.



chris