Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Allocating stack storage on Solaris?
42 views
Skip to first unread message
Nomen Nescio
Apr 25, 2012, 7:27:14 AM4/25/12
to
Is there a portable way within Solaris SPARC and Intel to allocate stack
storage? All I have found is alloca but it says behavior when you don't have
enough stack area is undefined. Not very pleasant. Is there another option?
Is this a bad idea? Thank you.
storage? All I have found is alloca but it says behavior when you don't have
enough stack area is undefined. Not very pleasant. Is there another option?
Is this a bad idea? Thank you.
Andrew Gabriel
Apr 25, 2012, 9:50:32 AM4/25/12
to
In article <012134cd96ae198a...@dizum.com>,
I suspect it means if you run off the stack, you'll crash as you
hit a no-access guard zone, exactly the same as if your function
stackframes run off the stack due to too deep function nesting,
and/or too much automatic data allocation in the functions.
If you're using it to do fairly small allocations, as you might
otherwise do with automatic array definitions in functions, then
I suspect you'll be fine.
Why do you want to use it instead of, say, malloc?
--
Andrew Gabriel
[email address is not usable -- followup in the newsgroup]
hit a no-access guard zone, exactly the same as if your function
stackframes run off the stack due to too deep function nesting,
and/or too much automatic data allocation in the functions.
If you're using it to do fairly small allocations, as you might
otherwise do with automatic array definitions in functions, then
I suspect you'll be fine.
Why do you want to use it instead of, say, malloc?
--
Andrew Gabriel
[email address is not usable -- followup in the newsgroup]
Paul Floyd
Apr 25, 2012, 3:31:46 PM4/25/12
to
In ISO C99 (and C11 I expect), you can declare dynamically sized arrays.
E.g.,
void foo(size_t x)
{
double a[x];
}
There are some restrictions on the use of this (things like
foo:
long z[q];
goto foo;
will probably cause problems.
If you need the code to work on Windows, then you won't be able to use
MS Visual Studio as Microsoft does not support C99 or C11.
A bientot
Paul
--
Paul Floyd http://paulf.free.fr
Ian Collins
Apr 25, 2012, 3:55:35 PM4/25/12
to
On 04/26/12 07:31 AM, Paul Floyd wrote:
> On Wed, 25 Apr 2012 13:27:14 +0200 (CEST), Nomen Nescio
> <nob...@dizum.com> wrote:
>> Is there a portable way within Solaris SPARC and Intel to allocate stack
>> storage? All I have found is alloca but it says behavior when you don't have
>> enough stack area is undefined. Not very pleasant. Is there another option?
>> Is this a bad idea? Thank you.
>
> Hi
>
> In ISO C99 (and C11 I expect), you can declare dynamically sized arrays.
>
> E.g.,
>
> void foo(size_t x)
> {
> double a[x];
> }
But these still suffer the same fate as alloca if you don't have enough
> On Wed, 25 Apr 2012 13:27:14 +0200 (CEST), Nomen Nescio
> <nob...@dizum.com> wrote:
>> Is there a portable way within Solaris SPARC and Intel to allocate stack
>> storage? All I have found is alloca but it says behavior when you don't have
>> enough stack area is undefined. Not very pleasant. Is there another option?
>> Is this a bad idea? Thank you.
>
> Hi
>
> In ISO C99 (and C11 I expect), you can declare dynamically sized arrays.
>
> E.g.,
>
> void foo(size_t x)
> {
> double a[x];
> }
space.
--
Ian Collins
Nomen Nescio
Apr 25, 2012, 7:23:09 PM4/25/12
to
comes when the stack frame is destroyed and processing should be much faster
than malloc. I don't exactly understand why alloca can't figure out if the
size you request exceeds the available storage though.
Ian Collins
Apr 25, 2012, 8:34:25 PM4/25/12
to
(VLAs). It has no means of returning an error. VLAs should be used in
place of alloca in new code: at least they make it clear the buffer is
local. In all the cases I've seen alloca used, the buffer size has been
small, so the risk of failure minimal but still real.
If you want scoped allocations, use C++ rather than C!
--
Ian Collins
Nomen Nescio
Apr 26, 2012, 2:24:05 AM4/26/12
to
Ian Collins <ian-...@hotmail.com> wrote:
> On 04/26/12 11:23 AM, Nomen Nescio wrote:
> > and...@cucumber.demon.co.uk (Andrew Gabriel) wrote:
> >
> >> In article<012134cd96ae198a...@dizum.com>,
> >> Nomen Nescio<nob...@dizum.com> writes:
> >>> Is there a portable way within Solaris SPARC and Intel to allocate stack
> >>> storage? All I have found is alloca but it says behavior when you don't have
> >>> enough stack area is undefined. Not very pleasant. Is there another option?
> >>> Is this a bad idea? Thank you.
> >>
> >> I suspect it means if you run off the stack, you'll crash as you
> >> hit a no-access guard zone, exactly the same as if your function
> >> stackframes run off the stack due to too deep function nesting,
> >> and/or too much automatic data allocation in the functions.
> >> If you're using it to do fairly small allocations, as you might
> >> otherwise do with automatic array definitions in functions, then
> >> I suspect you'll be fine.
> >>
> >> Why do you want to use it instead of, say, malloc?
> >
> > I thought it might be interesting to exploit the automatic deallocation that
> > comes when the stack frame is destroyed and processing should be much faster
> > than malloc. I don't exactly understand why alloca can't figure out if the
> > size you request exceeds the available storage though.
>
> alloca is a quick and dirty hack, now replaced by an equally dirty hack
> (VLAs). It has no means of returning an error.
That seems odd to me. Does the OS or libc or whoever's in charge of storage
> On 04/26/12 11:23 AM, Nomen Nescio wrote:
> > and...@cucumber.demon.co.uk (Andrew Gabriel) wrote:
> >
> >> In article<012134cd96ae198a...@dizum.com>,
> >> Nomen Nescio<nob...@dizum.com> writes:
> >>> Is there a portable way within Solaris SPARC and Intel to allocate stack
> >>> storage? All I have found is alloca but it says behavior when you don't have
> >>> enough stack area is undefined. Not very pleasant. Is there another option?
> >>> Is this a bad idea? Thank you.
> >>
> >> I suspect it means if you run off the stack, you'll crash as you
> >> hit a no-access guard zone, exactly the same as if your function
> >> stackframes run off the stack due to too deep function nesting,
> >> and/or too much automatic data allocation in the functions.
> >> If you're using it to do fairly small allocations, as you might
> >> otherwise do with automatic array definitions in functions, then
> >> I suspect you'll be fine.
> >>
> >> Why do you want to use it instead of, say, malloc?
> >
> > I thought it might be interesting to exploit the automatic deallocation that
> > comes when the stack frame is destroyed and processing should be much faster
> > than malloc. I don't exactly understand why alloca can't figure out if the
> > size you request exceeds the available storage though.
>
> alloca is a quick and dirty hack, now replaced by an equally dirty hack
> (VLAs). It has no means of returning an error.
really have no knowledge of allocation?
> VLAs should be used in place of alloca in new code: at least they make it
> clear the buffer is local.
> In all the cases I've seen alloca used, the buffer size has been small, so
> the risk of failure minimal but still real.
> If you want scoped allocations, use C++ rather than C!
Drazen Kacar
Apr 26, 2012, 11:53:00 AM4/26/12
to
Nomen Nescio wrote:
supposed to be fast.
> > VLAs should be used in place of alloca in new code: at least they make it
> > clear the buffer is local.
>
> I don't know what that is. I'll look it up.
Variable length arrays.
> > In all the cases I've seen alloca used, the buffer size has been small, so
> > the risk of failure minimal but still real.
>
> Risk of failure is not acceptable!
Why? You have the same risk of failure if your stack size is too small.
Stack size is normally controlled by the user and it's not customary for
applications to try to change it. If the application runs out of stack it
gets a signal which is supposed to terminate it. And that's how it should
be.
--
.-. .-. Yes, I am an agent of Satan, but my duties are largely
(_ \ / _) ceremonial.
|
| da...@fly.srk.fer.hr
> Ian Collins <ian-...@hotmail.com> wrote:
> > alloca is a quick and dirty hack, now replaced by an equally dirty hack
> > (VLAs). It has no means of returning an error.
>
> That seems odd to me. Does the OS or libc or whoever's in charge of storage
> really have no knowledge of allocation?
libc could gain that knowledge, but it beats the purpose. Alloca is
> > alloca is a quick and dirty hack, now replaced by an equally dirty hack
> > (VLAs). It has no means of returning an error.
>
> That seems odd to me. Does the OS or libc or whoever's in charge of storage
> really have no knowledge of allocation?
supposed to be fast.
> > VLAs should be used in place of alloca in new code: at least they make it
> > clear the buffer is local.
>
> I don't know what that is. I'll look it up.
> > In all the cases I've seen alloca used, the buffer size has been small, so
> > the risk of failure minimal but still real.
>
> Risk of failure is not acceptable!
Stack size is normally controlled by the user and it's not customary for
applications to try to change it. If the application runs out of stack it
gets a signal which is supposed to terminate it. And that's how it should
be.
--
.-. .-. Yes, I am an agent of Satan, but my duties are largely
(_ \ / _) ceremonial.
|
| da...@fly.srk.fer.hr
Andrew Gabriel
Apr 26, 2012, 1:19:36 PM4/26/12
to
In article <79cdd1b401c15d73...@dizum.com>,
Running off the stack isn't checked for in advance anyway.
The overhead of doing so on every stackframe allocation would
really clobber performance. If you do run off the stack, you'll
crash (even if you aren't using alloca). AFAIK, alloca() is
effectively implemented by the compiler, not by the OS or libc.
If you wanted to, you could call getcontext(2) and check how
far through the stack you are, but then you've lost the simplicity
and speed of using alloca.
>> VLAs should be used in place of alloca in new code: at least they make it
>> clear the buffer is local.
>
> I don't know what that is. I'll look it up.
>
>> In all the cases I've seen alloca used, the buffer size has been small, so
>> the risk of failure minimal but still real.
>
> Risk of failure is not acceptable!
How do you protect against your program running out of stack now?
In most cases, people just rely on the stack being much bigger
than they need. (If you're writing kernel code, particularly if
it had to run in 32 bit kernels, then the tiny stacks used were
something all kernel programmers had to be particularly aware of.)
The overhead of doing so on every stackframe allocation would
really clobber performance. If you do run off the stack, you'll
crash (even if you aren't using alloca). AFAIK, alloca() is
effectively implemented by the compiler, not by the OS or libc.
If you wanted to, you could call getcontext(2) and check how
far through the stack you are, but then you've lost the simplicity
and speed of using alloca.
>> VLAs should be used in place of alloca in new code: at least they make it
>> clear the buffer is local.
>
> I don't know what that is. I'll look it up.
>
>> In all the cases I've seen alloca used, the buffer size has been small, so
>> the risk of failure minimal but still real.
>
> Risk of failure is not acceptable!
In most cases, people just rely on the stack being much bigger
than they need. (If you're writing kernel code, particularly if
it had to run in 32 bit kernels, then the tiny stacks used were
something all kernel programmers had to be particularly aware of.)
Andreas F. Borchert
Apr 27, 2012, 10:02:46 AM4/27/12
to
On 2012-04-25, Nomen Nescio <nob...@dizum.com> wrote:
> I don't exactly understand why alloca can't figure out if the
> size you request exceeds the available storage though.
How much storage has been allocated for the stack is not directly
> I don't exactly understand why alloca can't figure out if the
> size you request exceeds the available storage though.
visible and you have to take into account that the kernel extends
the stack automatically to some extent (see ulimit).
You could, however, setup a signal handler for SIGSEGV that
handles such cases.
Andreas.
Casper H.S. Dik
Apr 27, 2012, 10:14:36 AM4/27/12
to
Casper
Andreas F. Borchert
Apr 27, 2012, 10:55:02 AM4/27/12
to
Andreas.
Fritz Wuehler
Apr 29, 2012, 5:35:50 AM4/29/12
to
call to allocate stack storage that verifies the amount you request is
available. Then it's like any other storage, if you run off the end it's a
programming error. However, to have no way of knowing how much stack there
is or having a function call that can't verify there is enough stack to
allocate, is unacceptable.
> The overhead of doing so on every stackframe allocation would
> really clobber performance. If you do run off the stack, you'll
> crash (even if you aren't using alloca).
> AFAIK, alloca() is effectively implemented by the compiler, not by the OS
> or libc.
accept your explanation.
> If you wanted to, you could call getcontext(2) and check how
> far through the stack you are, but then you've lost the simplicity
> and speed of using alloca.
> > Risk of failure is not acceptable!
>
> How do you protect against your program running out of stack now?
something. What a concept ;)
Ian Collins
Apr 29, 2012, 5:48:53 AM4/29/12
to
>> In article<79cdd1b401c15d73...@dizum.com>,
> I understand that but it *should* be. That's why I think there should be a
> call to allocate stack storage that verifies the amount you request is
> available. Then it's like any other storage, if you run off the end it's a
> programming error. However, to have no way of knowing how much stack there
> is or having a function call that can't verify there is enough stack to
> allocate, is unacceptable.
So don't use it, use dynamic allocation instead. A function that does
what you suggest may well be more expensive than a call to malloc.
>> The overhead of doing so on every stackframe allocation would
>> really clobber performance. If you do run off the stack, you'll
>> crash (even if you aren't using alloca).
>
> That could be avoided by actually designing a library call that helps.
Did you read what Andrew wrote?
>> AFAIK, alloca() is effectively implemented by the compiler, not by the OS
>> or libc.
>
> Ok. That is another typical UNIX finger-pointing, not-my-job non-design. I
> accept your explanation.
No, it's the way it is. alloca is and always (it has been around a long
time) has been a quick and dirty hack for allocating smallish buffers
off the stack. The proper C alternative (VLAs) are equally unpleasant.
--
Ian Collins
>> Nomen Nescio<nob...@dizum.com> writes:
>>> Ian Collins<ian-...@hotmail.com> wrote:
>>>
>>>> On 04/26/12 11:23 AM, Nomen Nescio wrote:
>>>>> and...@cucumber.demon.co.uk (Andrew Gabriel) wrote:
>>>>>
>>>>>> Why do you want to use it instead of, say, malloc?
>>>>>
>>>>> I thought it might be interesting to exploit the automatic deallocation that
>>>>> comes when the stack frame is destroyed and processing should be much faster
>>>>> than malloc. I don't exactly understand why alloca can't figure out if the
>>>>> size you request exceeds the available storage though.
>>>>
>>>> alloca is a quick and dirty hack, now replaced by an equally dirty hack
>>>> (VLAs). It has no means of returning an error.
>>>
>>> That seems odd to me. Does the OS or libc or whoever's in charge of storage
>>> really have no knowledge of allocation?
>>
>> Running off the stack isn't checked for in advance anyway.
Changed your name again?
>>> Ian Collins<ian-...@hotmail.com> wrote:
>>>
>>>> On 04/26/12 11:23 AM, Nomen Nescio wrote:
>>>>> and...@cucumber.demon.co.uk (Andrew Gabriel) wrote:
>>>>>
>>>>>> Why do you want to use it instead of, say, malloc?
>>>>>
>>>>> I thought it might be interesting to exploit the automatic deallocation that
>>>>> comes when the stack frame is destroyed and processing should be much faster
>>>>> than malloc. I don't exactly understand why alloca can't figure out if the
>>>>> size you request exceeds the available storage though.
>>>>
>>>> alloca is a quick and dirty hack, now replaced by an equally dirty hack
>>>> (VLAs). It has no means of returning an error.
>>>
>>> That seems odd to me. Does the OS or libc or whoever's in charge of storage
>>> really have no knowledge of allocation?
>>
>> Running off the stack isn't checked for in advance anyway.
> I understand that but it *should* be. That's why I think there should be a
> call to allocate stack storage that verifies the amount you request is
> available. Then it's like any other storage, if you run off the end it's a
> programming error. However, to have no way of knowing how much stack there
> is or having a function call that can't verify there is enough stack to
> allocate, is unacceptable.
what you suggest may well be more expensive than a call to malloc.
>> The overhead of doing so on every stackframe allocation would
>> really clobber performance. If you do run off the stack, you'll
>> crash (even if you aren't using alloca).
>
> That could be avoided by actually designing a library call that helps.
>> AFAIK, alloca() is effectively implemented by the compiler, not by the OS
>> or libc.
>
> Ok. That is another typical UNIX finger-pointing, not-my-job non-design. I
> accept your explanation.
time) has been a quick and dirty hack for allocating smallish buffers
off the stack. The proper C alternative (VLAs) are equally unpleasant.
--
Ian Collins
Drazen Kacar
Apr 29, 2012, 6:17:46 AM4/29/12
to
Fritz Wuehler wrote:
> > Running off the stack isn't checked for in advance anyway.
>
> I understand that but it *should* be. That's why I think there should be a
> call to allocate stack storage that verifies the amount you request is
> available. Then it's like any other storage, if you run off the end it's a
> programming error. However, to have no way of knowing how much stack there
> is or having a function call that can't verify there is enough stack to
> allocate, is unacceptable.
There be dragons in that cave. The C standard doesn't mention the word
> > Running off the stack isn't checked for in advance anyway.
>
> I understand that but it *should* be. That's why I think there should be a
> call to allocate stack storage that verifies the amount you request is
> available. Then it's like any other storage, if you run off the end it's a
> programming error. However, to have no way of knowing how much stack there
> is or having a function call that can't verify there is enough stack to
> allocate, is unacceptable.
"stack", nor should it. The existance of a stack is an implementation
detail and the standard should not mandate its existance. So a C language
function which would do anything with the stack is out of question.
C standard rationale mentions stack and explains that some design choices
were made to accomodate implementations which have a stack. And that is
as it should be. The alloca() function has always been a hack, usually
implemented by the compiler, but not necessarily so.
OTOH, POSIX is littered with functions that do something with the stack.
And at one place it says:
Attributes objects provide clean isolation of the configurable aspects
of threads. For example, "stack size" is an important attribute of a
thread, but it cannot be expressed portably. When porting a threaded
program, stack sizes often need to be adjusted. The use of attributes
objects can help by allowing the changes to be isolated in a single
place, rather than being spread across every instance of thread
creation.
Be a sport and take the time to research why stack size cannot be
expressed portably and share your findings with us.
> > The overhead of doing so on every stackframe allocation would
> > really clobber performance. If you do run off the stack, you'll
> > crash (even if you aren't using alloca).
>
> That could be avoided by actually designing a library call that helps.
inherently not portable because of hardware issues, then it's not possible
to design it. It is not obvious to me that there are no such hardware
issues.
> > AFAIK, alloca() is effectively implemented by the compiler, not by the OS
> > or libc.
>
> Ok. That is another typical UNIX finger-pointing, not-my-job non-design. I
> accept your explanation.
implementation. All three components (the compiler, OS and the standard
library) are equally responsible for the C run-time environment, so there
is no place for finger pointing.
> > If you wanted to, you could call getcontext(2) and check how
> > far through the stack you are, but then you've lost the simplicity
> > and speed of using alloca.
>
> Thanks I'll have a look.
Casper H.S. Dik
Apr 29, 2012, 6:28:51 AM4/29/12
to
Fritz Wuehler <fr...@spamexpire-201204.rodent.frell.theremailer.net> writes:
>I understand that but it *should* be. That's why I think there should be a
>call to allocate stack storage that verifies the amount you request is
>available. Then it's like any other storage, if you run off the end it's a
>programming error. However, to have no way of knowing how much stack there
>is or having a function call that can't verify there is enough stack to
>allocate, is unacceptable.
I believe the sun compiler has a mechanism top cope with some of these
>I understand that but it *should* be. That's why I think there should be a
>call to allocate stack storage that verifies the amount you request is
>available. Then it's like any other storage, if you run off the end it's a
>programming error. However, to have no way of knowing how much stack there
>is or having a function call that can't verify there is enough stack to
>allocate, is unacceptable.
errors:
-xcheck[=<a>[,<a>]] Generate runtime checks for error condition <a>={%all|%none|stkovf|no%stkovf|init_local|no%init_local}
(stkovf == stack overflow)
>> The overhead of doing so on every stackframe allocation would
>> really clobber performance. If you do run off the stack, you'll
>> crash (even if you aren't using alloca).
>That could be avoided by actually designing a library call that helps.
>> AFAIK, alloca() is effectively implemented by the compiler, not by the OS
>> or libc.
>Ok. That is another typical UNIX finger-pointing, not-my-job non-design. I
>accept your explanation.
Casper
Andreas F. Borchert
Apr 30, 2012, 11:30:05 AM4/30/12
to
On 2012-04-29, Casper H.S Dik <Caspe...@OrSPaMcle.COM> wrote:
> I believe the sun compiler has a mechanism top cope with some of these
> errors:
>
> -xcheck[=<a>[,<a>]] Generate runtime checks for error condition <a>={%all|%none|stkovf|no%stkovf|init_local|no%init_local}
>
> (stkovf == stack overflow)
>
[..]
> I believe the sun compiler has a mechanism top cope with some of these
> errors:
>
> -xcheck[=<a>[,<a>]] Generate runtime checks for error condition <a>={%all|%none|stkovf|no%stkovf|init_local|no%init_local}
>
> (stkovf == stack overflow)
>
> Whatever the mechanism used, it will be expensive.
"-xcheck=stkovf" is not expensive. If this option is given, the
compiler generates one or two extra load operations. The only effect
of this is that a SIGSEGV signal comes earlier.
Andreas.
Fritz Wuehler
May 1, 2012, 11:14:12 PM5/1/12
to
Drazen Kacar <da...@fly.srk.fer.hr> wrote:
> Fritz Wuehler wrote:
>
> > > Running off the stack isn't checked for in advance anyway.
> >
> > I understand that but it *should* be. That's why I think there should be a
> > call to allocate stack storage that verifies the amount you request is
> > available. Then it's like any other storage, if you run off the end it's a
> > programming error. However, to have no way of knowing how much stack there
> > is or having a function call that can't verify there is enough stack to
> > allocate, is unacceptable.
>
> There be dragons in that cave. The C standard doesn't mention the word
> "stack", nor should it. The existance of a stack is an implementation
> detail and the standard should not mandate its existance. So a C language
> function which would do anything with the stack is out of question.
I responded to all the posts so far but my emailer has reliability problems
> Fritz Wuehler wrote:
>
> > > Running off the stack isn't checked for in advance anyway.
> >
> > I understand that but it *should* be. That's why I think there should be a
> > call to allocate stack storage that verifies the amount you request is
> > available. Then it's like any other storage, if you run off the end it's a
> > programming error. However, to have no way of knowing how much stack there
> > is or having a function call that can't verify there is enough stack to
> > allocate, is unacceptable.
>
> There be dragons in that cave. The C standard doesn't mention the word
> "stack", nor should it. The existance of a stack is an implementation
> detail and the standard should not mandate its existance. So a C language
> function which would do anything with the stack is out of question.
and several posts never appeared. Sorry about that.
Thanks for your explanations. You obviously know a lot. However my question
is on the stack as implemented in Solaris, not on C's implementation. I am
looking for portability across Solaris both Intel and SPARC but it doesn't
have to be in C. It could be a syscall. Given the OS manages the stack it
seems like it *should* be a syscall.
> C standard rationale mentions stack and explains that some design choices
> were made to accomodate implementations which have a stack. And that is
> as it should be. The alloca() function has always been a hack, usually
> implemented by the compiler, but not necessarily so.
why it shouldn't have been done better. It seems to be proof that it wasn't
done better.
>
> OTOH, POSIX is littered with functions that do something with the stack.
> And at one place it says:
>
> Attributes objects provide clean isolation of the configurable aspects
> of threads. For example, "stack size" is an important attribute of a
> thread, but it cannot be expressed portably. When porting a threaded
> program, stack sizes often need to be adjusted. The use of attributes
> objects can help by allowing the changes to be isolated in a single
> place, rather than being spread across every instance of thread
> creation.
>
> Be a sport and take the time to research why stack size cannot be
> expressed portably and share your findings with us.
is another example of finger pointing. Since nobody owns the whole thing the
manuals are all discontiguous. I'd like to know what manuals I would have to
have that actually describe all of one UNIX implementation without gaps.
> > > The overhead of doing so on every stackframe allocation would
> > > really clobber performance. If you do run off the stack, you'll
> > > crash (even if you aren't using alloca).
> >
> > That could be avoided by actually designing a library call that helps.
>
> Provided that it's possible to design such a library call. If it's
> inherently not portable because of hardware issues, then it's not possible
> to design it. It is not obvious to me that there are no such hardware
> issues.
>
> > > AFAIK, alloca() is effectively implemented by the compiler, not by the OS
> > > or libc.
> >
> > Ok. That is another typical UNIX finger-pointing, not-my-job non-design. I
> > accept your explanation.
>
> That was not finger pointing, but rather an explanation of the usual
> implementation. All three components (the compiler, OS and the standard
> library) are equally responsible for the C run-time environment, so there
> is no place for finger pointing.
system where finger-pointing is inevitable. I think it's finger-pointing
when the OS depends on libc instead of providing all the stuff applications
need directly. Why the extra layer of libc? A good OS ought to be self
contained and provide all the essential functions as sys or kernel calls. A
good example of this falling down is essentially no heap storage management
without libc. Why does the OS not offer standard ways to do so that would
be useful to a piece of code running without libc? brk is not that useful of
a syscall. They did a half-assed job and libc has to pick up the slack. But
it doesn't always do that, as we are discussing.
The purpose of libraries ought to be to provide portability and extended
non-essential function. Throwing a compiler into the mix is also absurd. It
should do nothing more than exploit the library and system calls as
appropriate. If it implements its own services that don't exist in the
kernel or libc it makes things complicated for no reason. At the end of the
day each of the three areas (OS, library, compiler) all get to say it's not
my job and stuff isn't designed because they can always say that. That is
finger-pointing and it's one of the really bad things about UNIX. Nobody
owns the problem.
>
> > > If you wanted to, you could call getcontext(2) and check how
> > > far through the stack you are, but then you've lost the simplicity
> > > and speed of using alloca.
> >
> > Thanks I'll have a look.
>
> Not portable, IIRC, but I could be wrong.
Ian Collins
May 2, 2012, 1:35:46 AM5/2/12
to
On 05/ 2/12 03:14 PM, Fritz Wuehler wrote:
> Drazen Kacar<da...@fly.srk.fer.hr> wrote:
>
>> Fritz Wuehler wrote:
>>
>>>> Running off the stack isn't checked for in advance anyway.
>>>
>>> I understand that but it *should* be. That's why I think there should be a
>>> call to allocate stack storage that verifies the amount you request is
>>> available. Then it's like any other storage, if you run off the end it's a
>>> programming error. However, to have no way of knowing how much stack there
>>> is or having a function call that can't verify there is enough stack to
>>> allocate, is unacceptable.
>>
>> There be dragons in that cave. The C standard doesn't mention the word
>> "stack", nor should it. The existance of a stack is an implementation
>> detail and the standard should not mandate its existance. So a C language
>> function which would do anything with the stack is out of question.
>
> I responded to all the posts so far but my emailer has reliability problems
> and several posts never appeared. Sorry about that.
>
> Thanks for your explanations. You obviously know a lot. However my question
> is on the stack as implemented in Solaris, not on C's implementation. I am
> looking for portability across Solaris both Intel and SPARC but it doesn't
> have to be in C. It could be a syscall. Given the OS manages the stack it
> seems like it *should* be a syscall.
What part of it could be done but it would be expensive which defeats
> Drazen Kacar<da...@fly.srk.fer.hr> wrote:
>
>> Fritz Wuehler wrote:
>>
>>>> Running off the stack isn't checked for in advance anyway.
>>>
>>> I understand that but it *should* be. That's why I think there should be a
>>> call to allocate stack storage that verifies the amount you request is
>>> available. Then it's like any other storage, if you run off the end it's a
>>> programming error. However, to have no way of knowing how much stack there
>>> is or having a function call that can't verify there is enough stack to
>>> allocate, is unacceptable.
>>
>> There be dragons in that cave. The C standard doesn't mention the word
>> "stack", nor should it. The existance of a stack is an implementation
>> detail and the standard should not mandate its existance. So a C language
>> function which would do anything with the stack is out of question.
>
> I responded to all the posts so far but my emailer has reliability problems
> and several posts never appeared. Sorry about that.
>
> Thanks for your explanations. You obviously know a lot. However my question
> is on the stack as implemented in Solaris, not on C's implementation. I am
> looking for portability across Solaris both Intel and SPARC but it doesn't
> have to be in C. It could be a syscall. Given the OS manages the stack it
> seems like it *should* be a syscall.
the point of the function don't you recognise? If you want reliability,
use malloc/free.
--
Ian Collins
Drazen Kacar
May 2, 2012, 7:09:23 AM5/2/12
to
Fritz Wuehler wrote:
> Drazen Kacar <da...@fly.srk.fer.hr> wrote:
>
> > Fritz Wuehler wrote:
> > So a C language function which would do anything with the stack is out
> > of question.
>
> Drazen Kacar <da...@fly.srk.fer.hr> wrote:
>
> > Fritz Wuehler wrote:
> > So a C language function which would do anything with the stack is out
> > of question.
>
> Thanks for your explanations. You obviously know a lot. However my question
> is on the stack as implemented in Solaris, not on C's implementation.
I know. However, features must be implemented at some concrete level. I
> is on the stack as implemented in Solaris, not on C's implementation.
was explaining why the C language is not that layer. The useful part in
that is that in search for your feature you don't have to check C
standard, C standard rationale and the discuassion on the C
standardization mailing lists. You could check the archives of
comp.lang.c, though. There might be something interesting there.
> I am looking for portability across Solaris both Intel and SPARC but it
> doesn't have to be in C. It could be a syscall. Given the OS manages
> the stack it seems like it *should* be a syscall.
> > C standard rationale mentions stack and explains that some design choices
> > were made to accomodate implementations which have a stack. And that is
> > as it should be. The alloca() function has always been a hack, usually
> > implemented by the compiler, but not necessarily so.
>
> No offense but saying something has always been a hack isn't a good reason
> why it shouldn't have been done better. It seems to be proof that it wasn't
> done better.
view. Meaning it has no part in the language standard. That doesn't mean
it has no part anywhere else.
> > Be a sport and take the time to research why stack size cannot be
> > expressed portably and share your findings with us.
>
> I am trying to do that but the info I have so far isn't helping. The ABI doc
> is another example of finger pointing. Since nobody owns the whole thing the
> manuals are all discontiguous. I'd like to know what manuals I would have to
> have that actually describe all of one UNIX implementation without gaps.
standardization group and other resorces like that.
> I wasn't accusing you of finger pointing, I am accusing UNIX of setting up a
> system where finger-pointing is inevitable. I think it's finger-pointing
> when the OS depends on libc instead of providing all the stuff applications
> need directly.
kernel and libc and a few other libraries and applications together.
Whether the compiler is a part of the OS is a matter of discussion. It
used to be. :-)
> Why the extra layer of libc? A good OS ought to be self
> contained and provide all the essential functions as sys or kernel calls.
> A good example of this falling down is essentially no heap storage
> management without libc. Why does the OS not offer standard ways to do
> so that would be useful to a piece of code running without libc?
provides.
> brk is not that useful of a syscall. They did a half-assed job and libc
> has to pick up the slack.
virtue of that kind of separation is that you can substitute your own
implementation for the heap management and it work just fine. If
everything was in the kernel, substituting another implementation would be
harder or impossible.
> The purpose of libraries ought to be to provide portability and extended
> non-essential function.
should it be the purpose of every single library that anyone has ever
written?
> Throwing a compiler into the mix is also absurd. It
> should do nothing more than exploit the library and system calls as
> appropriate.
know whether any given function is a library call or a function
implemented by the application.
> If it implements its own services that don't exist in the
> kernel or libc it makes things complicated for no reason.
current alloca() implementation is one of them.) What's the point of
making that one instruction a library call? Just to make it slower?
> At the end of the day each of the three areas (OS, library, compiler)
> all get to say it's not my job and stuff isn't designed because they
> can always say that.
requires certain functionality. It's just that they don't care which layer
implements it. It's implementor's responsibility to implement the
functionality. The implementor, in case of Solaris, is Oracle. It's not
the compiler division inside Oracle or the kernel hackers corridor in one
of the Oracle's campuses.
Besides, the implementor should have the means to design his own
architecture, ie. to decide whether something goes into the compiler, libc
or the kernel. It doesn't affect your programs in any way. If you do write
them with a dependancy on a fixed layer (like using syscall() function),
you'll find that the official documentation says your program is not
portable and that fact is your problem, and not Solaris problem.
> That is finger-pointing and it's one of the really bad things about
> UNIX. Nobody owns the problem.
Fritz Wuehler
May 3, 2012, 7:31:20 AM5/3/12
to
Drazen Kacar <da...@fly.srk.fer.hr> wrote:
> Fritz Wuehler wrote:
> > Drazen Kacar <da...@fly.srk.fer.hr> wrote:
> >
> > > Fritz Wuehler wrote:
>
> > > So a C language function which would do anything with the stack is out
> > > of question.
> >
> > Thanks for your explanations. You obviously know a lot. However my question
> > is on the stack as implemented in Solaris, not on C's implementation.
>
> I know. However, features must be implemented at some concrete level. I
> was explaining why the C language is not that layer. The useful part in
> that is that in search for your feature you don't have to check C
> standard, C standard rationale and the discuassion on the C
> standardization mailing lists. You could check the archives of
> comp.lang.c, though. There might be something interesting there.
Thanks, good explanation.
> Fritz Wuehler wrote:
> > Drazen Kacar <da...@fly.srk.fer.hr> wrote:
> >
> > > Fritz Wuehler wrote:
>
> > > So a C language function which would do anything with the stack is out
> > > of question.
> >
> > Thanks for your explanations. You obviously know a lot. However my question
> > is on the stack as implemented in Solaris, not on C's implementation.
>
> I know. However, features must be implemented at some concrete level. I
> was explaining why the C language is not that layer. The useful part in
> that is that in search for your feature you don't have to check C
> standard, C standard rationale and the discuassion on the C
> standardization mailing lists. You could check the archives of
> comp.lang.c, though. There might be something interesting there.
> > > C standard rationale mentions stack and explains that some design choices
> > > were made to accomodate implementations which have a stack. And that is
> > > as it should be. The alloca() function has always been a hack, usually
> > > implemented by the compiler, but not necessarily so.
> >
> > No offense but saying something has always been a hack isn't a good reason
> > why it shouldn't have been done better. It seems to be proof that it wasn't
> > done better.
>
> I'm saying that alloca() has been a hack from the C standard point of
> view. Meaning it has no part in the language standard. That doesn't mean
> it has no part anywhere else.
(badly) it's a hack from any point of view.
> > I wasn't accusing you of finger pointing, I am accusing UNIX of setting up a
> > system where finger-pointing is inevitable. I think it's finger-pointing
> > when the OS depends on libc instead of providing all the stuff applications
> > need directly.
>
> My bad. I should have written "kernel" instead of "OS". The OS is
> kernel and libc and a few other libraries and applications together.
> Whether the compiler is a part of the OS is a matter of discussion. It
> used to be. :-)
>
> > Why the extra layer of libc? A good OS ought to be self
> > contained and provide all the essential functions as sys or kernel calls.
>
> Why? What is the virtue of that kind of architecture?
> > A good example of this falling down is essentially no heap storage
> > management without libc. Why does the OS not offer standard ways to do
> > so that would be useful to a piece of code running without libc?
>
> The standard way is usually implemented in libc and that is what the OS
> provides.
syscalls and a separate library and compilers that implement their own
services. UNIX people do like that design. You call it a separation, I call
it needless layers, complexity, finger-pointing and most of all bad
interface design where stuff eventually drops through the cracks. What's a
syscall? What's a libc call? What's the difference? Just give me a
monolithic service platform. Don't give me bullshit stories, give me
services.
> > Throwing a compiler into the mix is also absurd. It
> > should do nothing more than exploit the library and system calls as
> > appropriate.
>
> Compiler's primary job is to generate instructions. It usually doesn't
> know whether any given function is a library call or a function
> implemented by the application.
>
> > If it implements its own services that don't exist in the
> > kernel or libc it makes things complicated for no reason.
>
> There are things which are translated in a single instruction. (The
> current alloca() implementation is one of them.) What's the point of
> making that one instruction a library call? Just to make it slower?
> > At the end of the day each of the three areas (OS, library, compiler)
> > all get to say it's not my job and stuff isn't designed because they
> > can always say that.
>
> No. The C standard and the POSIX standard and every other damn standard
> requires certain functionality. It's just that they don't care which layer
> implements it. It's implementor's responsibility to implement the
> functionality. The implementor, in case of Solaris, is Oracle. It's not
> the compiler division inside Oracle or the kernel hackers corridor in one
> of the Oracle's campuses.
the problems it causes.
> Besides, the implementor should have the means to design his own
> architecture, ie. to decide whether something goes into the compiler, libc
> or the kernel. It doesn't affect your programs in any way.
everyone else so the way things were implemented *does* have an effect on
how code needs to be written.
> If you do write them with a dependancy on a fixed layer (like using
> syscall() function), you'll find that the official documentation says your
> program is not portable and that fact is your problem, and not Solaris
> problem.
as I said from the beginning. The question was on allocating stack storage
on Solaris Intel and SPARC.
> > That is finger-pointing and it's one of the really bad things about
> > UNIX. Nobody owns the problem.
>
> And the problem is?
nobody owns the problem. The libc guys say it's not our code. The OS says
I'll interrupt you if you touch an unallocated page. The compiler says sure
pal here's your storage, sortof, kinda, hope you like it and btw if you run
off the end it's not my problem it's the OS's problem. Unsafe services and
broken interfaces don't belong in a real OS. alloca() should let you know if
the request can't be satisfied or return you a pointer and length to how
much is available, etc. Fast and broken is crap.
Drazen Kacar
May 3, 2012, 9:52:48 AM5/3/12
to
Fritz Wuehler wrote:
> Drazen Kacar <da...@fly.srk.fer.hr> wrote:
> > Fritz Wuehler wrote:
> > I'm saying that alloca() has been a hack from the C standard point of
> > view. Meaning it has no part in the language standard. That doesn't mean
> > it has no part anywhere else.
>
> That is an important clarification but from your explanation of how it works
> (badly) it's a hack from any point of view.
It's a fast hack. Most things are a trade-off and the usuall alloca()
> Drazen Kacar <da...@fly.srk.fer.hr> wrote:
> > Fritz Wuehler wrote:
> > I'm saying that alloca() has been a hack from the C standard point of
> > view. Meaning it has no part in the language standard. That doesn't mean
> > it has no part anywhere else.
>
> That is an important clarification but from your explanation of how it works
> (badly) it's a hack from any point of view.
implementation gives you speed in exchange for the usual level of falling
off the stack security (ie. none).
> > > Why the extra layer of libc? A good OS ought to be self
> > > contained and provide all the essential functions as sys or kernel calls.
> >
> > Why? What is the virtue of that kind of architecture?
>
> Simplicity, correctness, and no UNIX-like who's got the banana
> finger-pointing.
> > The standard way is usually implemented in libc and that is what the OS
> > provides.
>
> This is the key point I guess. I don't like the UNIX design of a kernel with
> syscalls and a separate library and compilers that implement their own
> services. UNIX people do like that design.
thought.
> You call it a separation, I call it needless layers, complexity,
> finger-pointing and most of all bad interface design where stuff
> eventually drops through the cracks.
matter what you do and how you design things. Of finger-pointing's
existance I'm still not convinced, so no comment on that.
> What's a syscall? What's a libc call? What's the difference?
> Just give me a monolithic service platform. Don't give me bullshit
> stories, give me services.
> > Compiler's primary job is to generate instructions. It usually doesn't
> > know whether any given function is a library call or a function
> > implemented by the application.
>
> But you or Ian said alloca() is implemented by the compiler, so...
Alloca() translates to one or two instructions and it's nice to have a
compiler built-in to do that. There was a huge header file floating around
with programs that were using autoconf for configuration. That huge header
file implemented alloca() for platforms which didn't have it built in.
Besides, that which looks like a function could actually be a macro and it
frequently is. That's the way of C. I don't particularly like it, but it
never caused me any problems.
> > There are things which are translated in a single instruction. (The
> > current alloca() implementation is one of them.) What's the point of
> > making that one instruction a library call? Just to make it slower?
>
> Slow and correct beats fast and broken every time. Except on UNIX I guess.
Besides, I don't see how is one instruction wrapped in a function more
correct than that same one instruction inlined.
> > Besides, the implementor should have the means to design his own
> > architecture, ie. to decide whether something goes into the compiler, libc
> > or the kernel. It doesn't affect your programs in any way.
>
> Well it does to the extent everybody seems to have mindlessly copied
> everyone else so the way things were implemented *does* have an effect on
> how code needs to be written.
> > > That is finger-pointing and it's one of the really bad things about
> > > UNIX. Nobody owns the problem.
> >
> > And the problem is?
>
> The problem is according to you alloca() is a broken/unsafe service.
> And nobody owns the problem.
problem because nobody's supposed to do that. If you want different
functionality, you add another function.
> The libc guys say it's not our code. The OS says
> I'll interrupt you if you touch an unallocated page. The compiler says sure
> pal here's your storage, sortof, kinda, hope you like it and btw if you run
> off the end it's not my problem it's the OS's problem.
> Unsafe services and broken interfaces don't belong in a real OS.
and extending the memory region. They are using unsafe services because
that's exactly what they need. And then the memory management module makes
the whole thing safe and exports the interface to the rest of the program.
It would be very hard to implement your own memory management interface if
the OS was forcing you to use its own safe service.
> alloca() should let you know if the request can't be satisfied or
> return you a pointer and length to how much is available, etc.
> Fast and broken is crap.
that it generates that one machine instruction which cannot be generated
from the C code, so it saves me from inlining assembly.
Because of its hackish nature alloca() is not a part of the C standard and
not a part of the POSIX standard (and there are no other relevant
standards for this level of functionality, as far as I know). Those two
standards are defining serious and non-hackish language and operating
system and they don't include hackish things if at all possible. The
latest C standard even outlawed gets().
Creating a safe variant of alloca() isn't anyone's problem because it's
nonexistance is not a practical problem. And I don't understand why you
so desperately want that to become somebody's problem. If you're so
interested in creating that function, you could just write it and give it
to the rest of the world.
Fritz Wuehler
May 4, 2012, 12:43:42 PM5/4/12
to
Thanks Drazen. I appreciate your viewpoints. I don't agree but I like the
way you handle yourself.
Bill
way you handle yourself.
Bill
Fritz Wuehler
May 7, 2012, 6:21:30 PM5/7/12
to
correctly although a few people have said it would be 'expensive' what does
that mean exactly? At this points it's all winks and giggles. Second of all
if you can't do it correctly, imho you should not do it at all. That is
non-design, it's broken, it's bush league. Is the point of alloca letting
people shoot themselves in the foot or is it to be a useful service? If it's
supposed to be useful then it should work correctly. If there's enough stack
area to fulfill the request then fullfil it. If not allocate as much as
possible and return the number of bytes. The way it 'works' now is wrong and
you are defending that based on unknown or imaginary performance impact? If
stuff doesn't work right all the performance in the world isn't worth
anything. That should be obvious. Oh but this is UNIX where there are always
"good reasons" for doing things wrong.
According to you "If you want reliability, use malloc/free." Is that what
you really think, that it's ok that some services are reliable and others
aren't? What I really think is every libc or system call or compiler feature
ought to do The Right Thing and nobody should have to have special insider
knowledge to know which ones work reliably and which don't or choose between
a broken "fast" service and a slow "reliable" one. The fact some people
defend this broken finger-pointing not-my-job non-design of an "operating
system" is embarassing.
Ian Collins
May 7, 2012, 6:36:30 PM5/7/12
to
wrote up thread "alloca is a quick and dirty hack, now replaced by an
equally dirty hack (VLAs)" you will understand my position. I never use
either. The only code I have seen use alloca use it for small
allocations which are unlikely to fail. Do bear in mind that any
function call could result in stack exhaustion.
> According to you "If you want reliability, use malloc/free." Is that what
> you really think, that it's ok that some services are reliable and others
> aren't? What I really think is every libc or system call or compiler feature
> ought to do The Right Thing and nobody should have to have special insider
> knowledge to know which ones work reliably and which don't or choose between
> a broken "fast" service and a slow "reliable" one. The fact some people
> defend this broken finger-pointing not-my-job non-design of an "operating
> system" is embarassing.
they standardised VLAs!
--
Ian Collins
Casper H.S. Dik
May 8, 2012, 5:41:41 AM5/8/12
to
Fritz Wuehler <fr...@spamexpire-201205.rodent.frell.theremailer.net> writes:
>First of all nobody has discussed exactly what would be required to do it
>correctly although a few people have said it would be 'expensive' what does
>that mean exactly? At this points it's all winks and giggles. Second of all
>if you can't do it correctly, imho you should not do it at all. That is
>non-design, it's broken, it's bush league. Is the point of alloca letting
>people shoot themselves in the foot or is it to be a useful service? If it's
>supposed to be useful then it should work correctly. If there's enough stack
>area to fulfill the request then fullfil it. If not allocate as much as
>possible and return the number of bytes. The way it 'works' now is wrong and
>you are defending that based on unknown or imaginary performance impact? If
>stuff doesn't work right all the performance in the world isn't worth
>anything. That should be obvious. Oh but this is UNIX where there are always
>"good reasons" for doing things wrong.
There is really no difference from calling a function as that too requires
>First of all nobody has discussed exactly what would be required to do it
>correctly although a few people have said it would be 'expensive' what does
>that mean exactly? At this points it's all winks and giggles. Second of all
>if you can't do it correctly, imho you should not do it at all. That is
>non-design, it's broken, it's bush league. Is the point of alloca letting
>people shoot themselves in the foot or is it to be a useful service? If it's
>supposed to be useful then it should work correctly. If there's enough stack
>area to fulfill the request then fullfil it. If not allocate as much as
>possible and return the number of bytes. The way it 'works' now is wrong and
>you are defending that based on unknown or imaginary performance impact? If
>stuff doesn't work right all the performance in the world isn't worth
>anything. That should be obvious. Oh but this is UNIX where there are always
>"good reasons" for doing things wrong.
allocating memory on the stack nor is it different from specifiying a
VLA (variable length array) in a function.
>According to you "If you want reliability, use malloc/free." Is that what
>you really think, that it's ok that some services are reliable and others
>aren't? What I really think is every libc or system call or compiler feature
>ought to do The Right Thing and nobody should have to have special insider
>knowledge to know which ones work reliably and which don't or choose between
>a broken "fast" service and a slow "reliable" one. The fact some people
>defend this broken finger-pointing not-my-job non-design of an "operating
>system" is embarassing.
you run out of stack. But a programmer knows that the stack has certain
limits and should know how deep his functions will nest; we will understand
that he can't allocate many megabytes with alloca or in a VLA.
Even when alloca() succeeds, the next function called from that function
may fail because you run out of stack.
I'm not sure where you get the finger pointing from? The compiler, the
C library and the system are part of one single system. People have only
pointer out were things are implemented but not claiming that "it's done
by other people"; that is your *incorrect* assumption.
Also, there is really no point in arguing about alloca or how stacks work;
how they work is given. They cannot be changed.
They work fine for the purpose for which they have been designed.
Casper
Fritz Wuehler
May 10, 2012, 6:36:14 AM5/10/12
to
Casper H.S. Dik <Caspe...@OrSPaMcle.COM> wrote:
> alloca() is about as reliable as calling a function; it may fail because
> you run out of stack.
That is not what people have been saying. They said alloca() will succeed
> alloca() is about as reliable as calling a function; it may fail because
> you run out of stack.
when there isn't enough storage to allocate. Which is it?
> But a programmer knows that the stack has certain limits and should know
> how deep his functions will nest; we will understand that he can't
> allocate many megabytes with alloca or in a VLA.
on how many bytes exactly can he allocate. Exactly.
> Even when alloca() succeeds, the next function called from that function
> may fail because you run out of stack.
succeeds when you run out of stack. All I said was it should either fail
your request or return you the number or bytes it could allocate.
> I'm not sure where you get the finger pointing from? The compiler, the
> C library and the system are part of one single system. People have only
> pointer out were things are implemented but not claiming that "it's done
> by other people"; that is your *incorrect* assumption.
the point of POSIX, *the* compiler, the library, whatever that is, etc. So
now we have any UNIX involved, not just Solaris, any C compiler that runs in
that environment, and any libc. That could be Linux and glibc, it could be
Solaris with gcc instead of Studio, etc. Everybody claims bad or non-design
is everybody else's fault. I assumed nothing and your blowing smoke up your
own ass because there are right and wrong ways to do things and I know the
difference. And unlike you I don't defend broken designs by saying "we can't
talk about them because they already exist". That's bullshit. How are things
supposed to improve? Oh, they're not. It's UNIX. It's Broken By Non-Design.
> Also, there is really no point in arguing about alloca or how stacks work;
> how they work is given. They cannot be changed.
somebody say that how they work isn't correct? The kneejerk reactions and
pitiful defenses from the UNIX groupies are eerily like idol worship. Both
are based on nothing. Drazen was the only one who came close to actually
addressing the issue. The rest of you are having a group hug about how great
and unchangeable UNIX is. Whatever UNIX means.
> They work fine for the purpose for which they have been designed.
Ian Collins
May 10, 2012, 6:48:16 AM5/10/12
to
On 05/10/12 10:36 PM, Fritz Wuehler wrote:
>
> Super. So can you answer the question the thread started out with?
The first response you (or one of your other personae) received answered
>
> Super. So can you answer the question the thread started out with?
the original question.
--
Ian Collins
Casper H.S. Dik
May 10, 2012, 7:16:33 AM5/10/12
to
Fritz Wuehler <fr...@spamexpire-201205.rodent.frell.theremailer.net> writes:
>That is not what people have been saying. They said alloca() will succeed
>when there isn't enough storage to allocate. Which is it?
You misinterpret what I said; failing in the case of alloca() means that
>That is not what people have been saying. They said alloca() will succeed
>when there isn't enough storage to allocate. Which is it?
you will get memory you can't use.
>I asked the question specific to Solaris and everybody else answered from
>the point of POSIX, *the* compiler, the library, whatever that is, etc. So
>now we have any UNIX involved, not just Solaris, any C compiler that runs in
>that environment, and any libc. That could be Linux and glibc, it could be
>Solaris with gcc instead of Studio, etc. Everybody claims bad or non-design
>is everybody else's fault. I assumed nothing and your blowing smoke up your
>own ass because there are right and wrong ways to do things and I know the
>difference. And unlike you I don't defend broken designs by saying "we can't
>talk about them because they already exist". That's bullshit. How are things
>supposed to improve? Oh, they're not. It's UNIX. It's Broken By Non-Design.
it works. Period.
Casper
Casper H.S. Dik
May 10, 2012, 7:17:10 AM5/10/12
to
Casper
Nomen Nescio
May 10, 2012, 9:57:27 AM5/10/12
to
Casper H.S. Dik <Caspe...@OrSPaMcle.COM> wrote:
> Fritz Wuehler <fr...@spamexpire-201205.rodent.frell.theremailer.net> writes:
>
> >That is not what people have been saying. They said alloca() will succeed
> >when there isn't enough storage to allocate. Which is it?
>
> You misinterpret what I said; failing in the case of alloca() means that
> you will get memory you can't use.
How is what I said a misinterpretation of what you said? Do you want to play
>
> >That is not what people have been saying. They said alloca() will succeed
> >when there isn't enough storage to allocate. Which is it?
>
> You misinterpret what I said; failing in the case of alloca() means that
> you will get memory you can't use.
word games?
If you get memory you can't use is that not the same as succeeding when
there isn't enough storage to allocate? If not, how is it different in
practice?
> >I asked the question specific to Solaris and everybody else answered from
> >the point of POSIX, *the* compiler, the library, whatever that is, etc. So
> >now we have any UNIX involved, not just Solaris, any C compiler that runs in
> >that environment, and any libc. That could be Linux and glibc, it could be
> >Solaris with gcc instead of Studio, etc. Everybody claims bad or non-design
> >is everybody else's fault. I assumed nothing and your blowing smoke up your
> >own ass because there are right and wrong ways to do things and I know the
> >difference. And unlike you I don't defend broken designs by saying "we can't
> >talk about them because they already exist". That's bullshit. How are things
> >supposed to improve? Oh, they're not. It's UNIX. It's Broken By Non-Design.
>
> No; they're not saying it is someone else fault. They're describing how
> it works. Period.
can't be changed. That is not the same as what you said.
Richard B. Gilbert
May 10, 2012, 4:06:45 PM5/10/12
to
broken and cannot be changed because . . . .
Perhaps someone can rewrite it in a more logical and straightforward manner!
ChrisQ
May 10, 2012, 5:04:31 PM5/10/12
to
On 05/10/12 20:06, Richard B. Gilbert wrote:
>>> No; they're not saying it is someone else fault. They're describing how
>>> it works. Period.
>>
>> No, they have been saying that's the way it is *and* it's broken *and* it
>> can't be changed. That is not the same as what you said.
>>
>>
>
> It can't be changed? Why not? It would be more useful to say "it's
> broken and cannot be changed because . . . .
>
> Perhaps someone can rewrite it in a more logical and straightforward
> manner!
>
>
Isn't this all a bit academic anyway. in that alloca() is a Linux system
>>> No; they're not saying it is someone else fault. They're describing how
>>> it works. Period.
>>
>> No, they have been saying that's the way it is *and* it's broken *and* it
>> can't be changed. That is not the same as what you said.
>>
>>
>
> It can't be changed? Why not? It would be more useful to say "it's
> broken and cannot be changed because . . . .
>
> Perhaps someone can rewrite it in a more logical and straightforward
> manner!
>
>
call and, afaics, isn't part of Solaris ?. If any system call returns ok
when it isn't, then that bug needs to be fixed.
In general, if any programmer is allocating stack space, then he or she is
expected to understand the risks and have a clue as to how much stack can
be safely allocated. Anything else would seem like incompetence. Processes
would ideally be allocated stack space based on some system tuning
parameter,
per process, or specified as part of the run time environment for that
process...
Regards,
Chris
ChrisQ
May 10, 2012, 5:31:20 PM5/10/12
to
Internals book (P84) discusses this at length, using plimit:
$ plimit $$
27969: bash
resource current maximum
time(seconds) unlimited unlimited
file(blocks) unlimited unlimited
data(kbytes) unlimited unlimited
stack(kbytes) 8192 unlimited
coredump(blocks) unlimited unlimited
nofiles(descriptors) 256 65536
vmemory(kbytes) unlimited unlimited
Then, to set per process limits:
$ plimit
usage:
For each process, report all resource limits:
plimit [-km] pid ...
-k report file sizes in kilobytes
-m report file/memory sizes in megabytes
For each process, set specified resource limits:
plimit -{cdfnstv} soft,hard ... pid ...
-c soft,hard set core file size limits
-d soft,hard set data segment (heap) size limits
-f soft,hard set file size limits
-n soft,hard set file descriptor limits
-s soft,hard set stack segment size limits
-t soft,hard set CPU time limits
-v soft,hard set virtual memory size limits
(default units are as shown by the output of 'plimit pid')
I guess the easiest way to allocate space on the stack is to declare
an array (non static) within the function which is within the process
stack limit. As for setting the stack limit, I don't do enough Solaris
dev to say, but that should ideally be specifiable at link time...
Is there a better way ?...
Reagrds,
Chris
Chris Ridd
May 11, 2012, 1:31:22 AM5/11/12
to
On 2012-05-10 21:04:31 +0000, ChrisQ said:
> Isn't this all a bit academic anyway. in that alloca() is a Linux system
> call and, afaics, isn't part of Solaris ?.
I remember alloca() from SunOS 4, certainly boxes that existed before Linux.
> Isn't this all a bit academic anyway. in that alloca() is a Linux system
> call and, afaics, isn't part of Solaris ?.
The Linux man page suggests it was in "32V, PWB, PWB.2, 3BSD, and
4BSD". <http://linux.die.net/man/3/alloca>
--
Chris
Casper H.S. Dik
May 11, 2012, 3:37:32 AM5/11/12
to
ChrisQ <me...@devnull.com> writes:
>I guess the easiest way to allocate space on the stack is to declare
>an array (non static) within the function which is within the process
>stack limit. As for setting the stack limit, I don't do enough Solaris
>dev to say, but that should ideally be specifiable at link time...
>Is there a better way ?...
Depending on the architecture, the shared libraries might map directly
>I guess the easiest way to allocate space on the stack is to declare
>an array (non static) within the function which is within the process
>stack limit. As for setting the stack limit, I don't do enough Solaris
>dev to say, but that should ideally be specifiable at link time...
>Is there a better way ?...
under the stack limit. (32 bit x86 is the exception)
So you can't increate the limit in a running process as there simply
no room. It might be possible change it when linking (using mapfiles).
There are also threads and there is no way to influence the size of
the stack for a thread outside of the program; the programmer needs
to decide the size of the stack (the default is 1MB)
Casper
Drazen Kacar
May 11, 2012, 3:49:10 AM5/11/12
to
operating system which changes semantics of its functions just because
somebody (possibly quite reasonably) decided that they are not good.
In those cases new calls are *added*. That preserves compatibility with
the old code and implemets the new (presumably better) functions. So
there's no barrier to implementing alloca1[1] for example. Or alloca_s, if
you prefer that name, although I wouldn't use it because the C standard
has started to use "_s" postfix for safe function versions, so I wouldn't
want to trample in their namespace.
But again, nobody has said that the safe version of alloca can't be
implemented. People were saying that the current one is not going to be
changed.
[1] Adding "1" is in line with the existing function names like fork1
and dladdr1, although there is umount2, but not umount1. :-)
Casper H.S. Dik
May 11, 2012, 5:24:32 AM5/11/12
to
Drazen Kacar <da...@fly.srk.fer.hr> writes:
>In those cases new calls are *added*. That preserves compatibility with
>the old code and implemets the new (presumably better) functions. So
>there's no barrier to implementing alloca1[1] for example. Or alloca_s, if
>you prefer that name, although I wouldn't use it because the C standard
>has started to use "_s" postfix for safe function versions, so I wouldn't
>want to trample in their namespace.
>But again, nobody has said that the safe version of alloca can't be
>implemented. People were saying that the current one is not going to be
>changed.
>[1] Adding "1" is in line with the existing function names like fork1
> and dladdr1, although there is umount2, but not umount1. :-)
The numeric post-fix is typicaly not a version number but the nummer
>In those cases new calls are *added*. That preserves compatibility with
>the old code and implemets the new (presumably better) functions. So
>there's no barrier to implementing alloca1[1] for example. Or alloca_s, if
>you prefer that name, although I wouldn't use it because the C standard
>has started to use "_s" postfix for safe function versions, so I wouldn't
>want to trample in their namespace.
>But again, nobody has said that the safe version of alloca can't be
>implemented. People were saying that the current one is not going to be
>changed.
>[1] Adding "1" is in line with the existing function names like fork1
> and dladdr1, although there is umount2, but not umount1. :-)
of arguments in the newer version:
mount, mount2
dup, dup2
wait, wait3, wait4
And fork1() was named such because only one thread was running
in the child (that is the behaviour of Solaris 10 and later or
when using POSIX thread on earlier versions of Solaris)
Casper
Nomen Nescio
May 13, 2012, 5:05:04 AM5/13/12
to
Casper H.S. Dik <Caspe...@OrSPaMcle.COM> wrote:
> There are also threads and there is no way to influence the size of
> the stack for a thread outside of the program; the programmer needs
> to decide the size of the stack (the default is 1MB)
Does the programmer have any control over this? As far as I saw the sysadmin
> the stack for a thread outside of the program; the programmer needs
> to decide the size of the stack (the default is 1MB)
sets tunable kernel parameters. And where are you getting a default of 1MB
from, is that for S11?
The S10 Tunable Parameters Reference Manual says (default_stksize) the
default is 3xPAGESIZE on SPARC, 2xPAGESIZE on x86, and 5xPAGESIZE on AMD64
and those are the minimums. It says the maximum is 32x the default value
although that seems to contradict a statement a few lines down that the
value is validated against a maximum value of 262,144 (256 x 1024) bytes and
must also be a multiple of the page size.
The default page size for S10 is 4096 on the amd64 copy I am testing at the
moment. That means the default stacksize is 20K, not 1MB.
Ian Collins
May 13, 2012, 5:11:41 AM5/13/12
to
A new thread created with pthread_create() uses the stack
specified by the stackaddr attribute, and the stack contin-
ues for the number of bytes specified by the stacksize
attribute. By default, the stack size is 1 megabyte for 32-
bit processes and 2 megabyte for 64-bit processes (see
pthread_attr_setstacksize(3C)). If the default is used for
both the stackaddr and stacksize attributes,
pthread_create() creates a stack for the new thread with at
least 1 megabyte for 32-bit processes and 2 megabyte for
64-bit processes.
--
Ian Collins
0 new messages