«

In article <bma3so$48l$>
Sidney Cadot <> writes:
>I think the issue here is to distinguish between something that
>/logically/ behaves like a stack, and something that is a classical
>stack implementation as supported by many hardware platforms.
>
>Reading Chris' reply I feel that his statement amounted to the effect
>that, given the constraints in the Standard, it follows that an
>implementation must support something that behaves like a /logical/ stack.

Yes. Any queue data structure with last-in-first-out and "top
entry is visible" can be called a "stack", and the values of
variables within a function activation fit this description.

The main problem with saying that local variables are "on the
stack", or even "on a stack", is that people may -- and do in
practice -- draw invalid (in the general case, at least) conclusions
from this wording. We might safely say "local variables participate
in a stack discipline" or "behave in a stack-like manner", but at
that point the meaning may no longer be clear to the reader.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://67.40.109.61/torek/index.html (for the moment)
Reading email is like searching for food in the garbage, thanks to spammers.

Chris Torek wrote:
> Sidney Cadot <> writes:
> >Joona I Palaste wrote:
>
> >> There is no requirement for implementations to *have* a stack
> >> in the first place.
>
> > This is the second time I see this posted over the last couple
> > of days, and you're surely right.
>
> In a technical sense, at least, and it *does* matter sometimes.
>
> The constraints in the standard force "stack-like behavior" for
> local variables inside functions (including any parameters), and
> I think it is not out of line to call this "a stack". But one
> should remember that this "stack" may well be implemented as,
> e.g., a linked list of frames:

I just came up with a new system that can confuse many programs
that take liberties.

Assuming that byte, short, int, long are all an increasing size,
i.e. 1,2,4,8, and that we can fit float and double in there, lets
have a machine with 4 separate stacks, separated by size.

We can also have an assortment of sized registers, each of which
represents the top of a stack of items of its own size.

I think it would be a feasible machine. Might be a good basis for
the DS9000.

--
Chuck F () ()
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

On Sun, 12 Oct 2003 03:16:36 +0200, Sidney Cadot <> wrote:

>Message-ID: <bmaa15$61s$>
>Subject: Re: why does this work ?
>From: Sidney Cadot <>
>Newsgroups: comp.lang.c
>Date: Sun, 12 Oct 2003 03:16:36 +0200
>
>Hi Mark,
>
>>>I think the issue here is to distinguish between something that
>>>/logically/ behaves like a stack,
>
>> In what way does the standard /REQUIRE/ the logical behaviour of a
>> stack.
>
>Well, in a very obvious way really. Actual parameters and local
>variables are accessible during execution of a function; they become
>inaccessible during a recursive call as the same formal parameters and
>local variables now refer to new, independent variables, which cease to
>exist upon return from the secondary call to the same function. I think
>you will agree that this behavior is prescribed by the standard.
>
>To me at least, this seems equivalent to viewing the set of parameters
>and local variables as a tuple; the ordered list of these tuples
>associated with recursive invocations of a function, of which only the
>current one is accessible, has all the hallmark properties of a stack of
>which only the top-most element is accessible at any given time.
>
>> Thats as opposed to "S Cabot needs an internal mental picture of how
>> function calls etc work, and he finds the idea of a stack easy to
>> visualise and operate with". No offense intended.
>
>None taken, not even for misspelling my name
>
>> For myself I don't need this mental picture. I think of function
>> calls, recurnsion and automatics as involving the computer storing
>> different data in various places, and remembering where it is at the
>> relevant time.
>
>My main argument in this thread is not whether C prescribes a logical
>stack or not; for me that's a useful model (so good, in fact, that I
>would be interested to see where this model falls apart), and for you it
>isn't. That's A-ok by me.
>
>On the risk of committing speculation, I think you would be hard-pressed
>to find a compiler implementor who doesn't use the stack as a very
>useful model while implementing a C (or any other) compiler.
>
>What I /would/ like to get to is the phenomenon that a seemingly
>standard-compliant program can exhibit undefined behavior. There's a
>number of explanations (perhaps there are more):
>
>* the standard does in fact cover this case through a specific limit
> exceeded (for example) by my small program, and nobody mentioned
> it so far in this thread.
>* the standard does in fact cover this case, as it presumes an
> idealized machine where certain practical constraints do not
> hold (I'd welcome a clear reference).
>* the standard does not cover this case.
>
>Presuming for the moment that the third case is what's going on, I think
>it is a worthwile exercise to ponder if/how the standard could be
>amended in such a way as to cover this case. Stack overflow (perhaps
>'resource depletion due to many nested function calls' is a better, but
>clumsier term), in my opinion, is a phenomenon that is important enough
>to deserve mention in the standard. I would be interested to know if
>people disagree with this.
>
>> A bit like me working on something, and using various books from my
>> bookshelf. I feel no compulsion to make a "stack" of hte ones I need,
>> pushing the most recently used one to the top, and then popping it off
>> again when I'm done. I merely pull them off the shelf when needed, and
>> put 'em back afterwards, generally in much the same place but a few
>> books to the left or right doesn't matter, I'm no Dewey obsessive.
>
>But then, you're not a running C program which, I hope, exhibits a level
>of neurotic-obsessive behavior that would make a clinical psychiatrist
>dance with joy.
>
>Best regards,
>
> Sidney Cadot

---------------------------------------
Posted with JOC News Finder
Download at http://www.jocsoft.com/jnf/

Sidney Cadot <> writes:


>
> * the standard does in fact cover this case through a specific limit
> exceeded (for example) by my small program, and nobody mentioned
> it so far in this thread.
> * the standard does in fact cover this case, as it presumes an
> idealized machine where certain practical constraints do not
> hold (I'd welcome a clear reference).

I would vote for this one, as you are exceeding the required minimum
number of objects with your recursive calls ( you have one auto
variable per call, where the lifetime ends on return of the function.)


Björn

--
Bjoern Pedersen Lichtenbergstr.1
Technische Universitaet Muenchen D-85747 Garching
ZWE Instrumentierung FRM-II
Tel. + 49 89 289-14707 Fax -14666

On Sun, 12 Oct 2003 03:16:36 +0200, in comp.lang.c , Sidney Cadot
<> wrote:

>Hi Mark,
>
>>>I think the issue here is to distinguish between something that
>>>/logically/ behaves like a stack,
>
>> In what way does the standard /REQUIRE/ the logical behaviour of a
>> stack.
>
>Well, in a very obvious way really. Actual parameters and local
>variables are accessible during execution of a function; they become
>inaccessible during a recursive call as the same formal parameters and
>local variables now refer to new, independent variables, which cease to
>exist upon return from the secondary call to the same function. I think
>you will agree that this behavior is prescribed by the standard.

it is, but its not necessary for a stack to be used either literally
or logically to achieve this. I have a ladder to access the top shelf
of my books. When I'm pulling down Sci Fi books, I can't access my C
books, and vice versa. But I still don't have a stack of books with
LIFO type behaviour.

>To me at least, this seems equivalent to viewing the set of parameters
>and local variables as a tuple;

sure, you can regard it that way, its your mindset. I'm just trying to
make clear that the standard doesn't require you to think of it like
that, or implementors to implement it thus

>My main argument in this thread is not whether C prescribes a logical
>stack or not;

IMHO it does not.

>for me that's a useful model

Thats ok with me. I don't feel the need to have it.

>On the risk of committing speculation, I think you would be hard-pressed
>to find a compiler implementor who doesn't use the stack as a very
>useful model while implementing a C (or any other) compiler.

I suspect this discussion is now well into the realm of
comp.compilers. Perhaps you should continue it over there?


--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>


----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

Hi Mark,

> [snip]

>>My main argument in this thread is not whether C prescribes a logical
>>stack or not;
>
> IMHO it does not.
>
>>for me that's a useful model
>
> Thats ok with me. I don't feel the need to have it.
>
>>On the risk of committing speculation, I think you would be hard-pressed
>>to find a compiler implementor who doesn't use the stack as a very
>>useful model while implementing a C (or any other) compiler.
>
> I suspect this discussion is now well into the realm of
> comp.compilers. Perhaps you should continue it over there?



As stated, my main argument in this thread is not whether C prescribes a
logical stack or not; rather, it is to find out if stack overflows are
covered by the standard, one way or another.

We differ on whether we feel the need to internalize the C runtime model
as a stack; I'm comfortable with that, as are you. Let's just keep it at
that and move on to more interesting matters.

Best regards,

Sidney Cadot

Hi Björn,

>>* the standard does in fact cover this case, as it presumes an
>> idealized machine where certain practical constraints do not
>> hold (I'd welcome a clear reference).

> I would vote for this one, as you are exceeding the required minimum
> number of objects with your recursive calls ( you have one auto
> variable per call, where the lifetime ends on return of the function.)

I am not aware of a requirement in the Standard that prescribes a
minimum number of active objects that an implementation must support
(where 'object' includes things like parameters and automatic
variables). Do you have a reference?

For sure, if there is one, the sample program may well exceed it at some
point. I, for one, would be quite satisfied if you are right.

Best regards,

Sidney Cadot

Sidney Cadot <> writes:

> > I would vote for this one, as you are exceeding the required minimum
> > number of objects with your recursive calls ( you have one auto
> > variable per call, where the lifetime ends on return of the function.)
>
> I am not aware of a requirement in the Standard that prescribes a
> minimum number of active objects that an implementation must support
> (where 'object' includes things like parameters and automatic
> variables). Do you have a reference?
>
That's the Translation Limits section. I don't have the standard at
hand, but it should be around 5.2.4.1 (see post from C. Torek
upthread). Maybe some of the language lawyers here can give a better
reference.

Björn




--
Bjoern Pedersen Lichtenbergstr.1
Technische Universitaet Muenchen D-85747 Garching
ZWE Instrumentierung FRM-II
Tel. + 49 89 289-14707 Fax -14666

Bjoern Pedersen <> wrote:

>Sidney Cadot <> writes:
>>
>> I am not aware of a requirement in the Standard that prescribes a
>> minimum number of active objects that an implementation must support
>> (where 'object' includes things like parameters and automatic
>> variables). Do you have a reference?
>>
>That's the Translation Limits section. I don't have the standard at
>hand, but it should be around 5.2.4.1 (see post from C. Torek
>upthread).

I cannot find anything in or around ISO/IEC 9899:1999 5.2.4.1 that
addressess the mentioned problem. This is the part from Chris Torek's
post you are probably referring to:

SC: ... is there a minimum depth of function calls that I can rely on
SC: to be executed properly? ...

CT: I have never found one. The "Translation limits" section (at or
CT: near 5.2.4.1) is the logical place for something like "at least N
CT: function activations down from the initial call to main()", but
CT: there is no such wording. On the other hand, that section is not
CT: a good weapon against Evil Compilers, as it requires only that an
CT: implementation "translate and execute ... one program" that tests
CT: those limits.

>Maybe some of the language lawyers here can give a better reference.

Regards
--
Irrwahn
()

Irrwahn Grausewitz <> writes:

> Bjoern Pedersen <> wrote:
>
> >Sidney Cadot <> writes:
> >>
> >> I am not aware of a requirement in the Standard that prescribes a
> >> minimum number of active objects that an implementation must support
> >> (where 'object' includes things like parameters and automatic
> >> variables). Do you have a reference?
> >>

> SC: ... is there a minimum depth of function calls that I can rely on
> SC: to be executed properly? ...


The problem I addressed was the number of objects allocated by the
example ( it had a local auto variable). This is covered by the normal
allocation limits. A function not allocating anything (i.e. no locals,
no parameters) colud probabaly be called indefinitly.

Björn
--
Bjoern Pedersen Lichtenbergstr.1
Technische Universitaet Muenchen D-85747 Garching
ZWE Instrumentierung FRM-II
Tel. + 49 89 289-14707 Fax -14666