What is a stack frame?
jacob navia
with "stack frame". I think that it is important for people using the
language, that this important concept is clear, so I have produced
this post.
Obviously, there are some people here that live in some
special world where all those things do not exist. They should stay
there and ignore this thread. The same goes for all people that
program in coffee machines and other primitive processors that
do not have a stack pointer or enough registers to use a stack
efficiently.
----------------------
What is a stack frame?
---------------------
Within a stack, each procedure builds a "stack frame", i.e. a fixed
point within the stack, where storage for local variables is reserved.
The stack frames are a linked list of this storage areas. This builds
the conceptual stack that the language needs. Each stack frame is
linked to the previous one. A new stack frame is built when a
procedure is entered, and it is popped from the stack of stack frames
at the procedure exit.
The "main" function has the first (visible) frame, and each stack
frame built in one of the functions called after "main" started is
linked to that stack frame. This makes it possible for debuggers
and other tools to "walk the stack" of called procedures.
We can (conceptually) describe the stack frame as follows
struct tagStackFrame {
void *Previous;
void *ThisFrame;
char LocalStorage[];
};
The "Next" member is a pointer to the previous function's stack frame,
the "ThisFrame" pointer points to the current stack frame, and the
Local storage is made out of different variables that a function
declares. We can imagine that the local storage of deeper nested
blocks is added to the function's local storage, even if it is not
visible (i.e. can't be accessed) after its scope disappears.
Building the stack frame (Prologue)
------------------------
The first thing to do to build a stack frame is then, to save in the
"Previous" slot, the value of the current stack frame pointer.
Normally, this is a dedicated register. For instance, the power PC
version of lcc-win uses register 31. This register is normally
defined by the operating system ABI (Application Binary Interface)
since ALL programs running in the same operating system MUST agree
as to what the frame pointer register is, if not CHAOS is surely the
consequence.
After saving the current FP (or Frame Pointer) we copy the current
value of the stack pointer into the frame pointer, to establish a new
stack frame from this stack position on. We fill then, the "ThisFrame"
slot of our structure, and lastly, we subtract from the frame pointer
the amount of space needed by the function's local variables, our
"Local storage" member.
There exist MANY variation of this scheme. Some optimizing compilers
save themselves the trouble of having a different register than the
stack pointer to build a stack frame, and just use the stack pointer to
address local variables. Conceptually however, nothing changes.
Popping the stack frame (Epilogue)
-----------------------
A function must restore the previous stack frame before leaving the
scene. This is done in the reverse order of the previous actions. The
space allocated for local variables is released by adjusting the stack
pointer, the previous value of the stack frame is popped from the stack,
and the function can now return.
Other stuff
-----------
A function uses registers to do its calculations. Those register can be
scratch registers, i.e. registers that can be used without having to
save them, or they can be registers that need save before use, to
preserve their value across function calls. The saved registers are part
of the stack frame, even if I did not mention that above to keep things
simple. They are restored before the current function exits.
Another thing to be known is "alloca". This function allocates storage
from the stack by decreasing the stack pointer. A function that calls
alloca must do the popping of the current stack frame in a different
manner since the current stack frame is "deformed" by alloca.
And yet another thing: in standard C, we can have objects whose size
is allocated in local storage but whose exact size is unknown until
run time. This is similar to alloca, and produces the same consequences.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Richard Heathfield
> Recently K. Thompson asked me to specify what did I understand
> with "stack frame". I think that it is important for people using the
> language, that this important concept is clear, so I have produced
> this post.
Have you considered posting this in a newsgroup where it's relevant, such
as, perhaps, comp.arch?
> Obviously, there are some people here that live in some
> special world where all those things do not exist.
Well, there are many such worlds, of which comp.lang.c is one, yes. Others
include rec.scuba, alt.folklore.urban, and sci.med.dentistry. I note that
you did not post this article to those groups. Why post it to comp.lang.c?
<snip>
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Bartc
"jacob navia" <ja...@nospam.com> wrote in message
news:fqgksq$eja$1...@aioe.org...
> The first thing to do to build a stack frame is then, to save in the
> "Previous" slot, the value of the current stack frame pointer.
> Normally, this is a dedicated register. For instance, the power PC
> version of lcc-win uses register 31. This register is normally
> defined by the operating system ABI (Application Binary Interface)
I think it is specified by the architecture where there is special support
for a frame pointer. But even then implementations can make whatever
arrangements they like.
> since ALL programs running in the same operating system MUST agree
> as to what the frame pointer register is, if not CHAOS is surely the
> consequence.
That sounds unlikely.
> Some optimizing compilers
> save themselves the trouble of having a different register than the
> stack pointer to build a stack frame, and just use the stack pointer to
> address local variables.
And clearly 'chaos' does not result.
The point is all this stuff depends on the implementation of the language
and varies from system to system. Probably most implementations will have
some sort of stack and maybe some will use some concept of a frame pointer,
and sometimes it might be helpful to bear all this in mind. But your details
are far too specific.
--
Bart
jacob navia
> "jacob navia" <ja...@nospam.com> wrote in message
> news:fqgksq$eja$1...@aioe.org...
>
>> The first thing to do to build a stack frame is then, to save in the
>> "Previous" slot, the value of the current stack frame pointer.
>> Normally, this is a dedicated register. For instance, the power PC
>> version of lcc-win uses register 31. This register is normally
>> defined by the operating system ABI (Application Binary Interface)
>
> I think it is specified by the architecture where there is special support
> for a frame pointer. But even then implementations can make whatever
> arrangements they like.
Arrangements that MUST be compatible with the ABI. Here we have the
"as if rule": an implementation could use other registers for the
frame pointer as long as it does NOT trash the value in the official
frame pointer.
>
>> since ALL programs running in the same operating system MUST agree
>> as to what the frame pointer register is, if not CHAOS is surely the
>> consequence.
>
> That sounds unlikely.
>
Try trashing the frame pointer then, and see what happens.
>> Some optimizing compilers
>> save themselves the trouble of having a different register than the
>> stack pointer to build a stack frame, and just use the stack pointer to
>> address local variables.
>
> And clearly 'chaos' does not result.
>
Because they preserve the frame pointer register.
> The point is all this stuff depends on the implementation of the language
> and varies from system to system.
The general setup I described does NOT.
> Probably most implementations will have
> some sort of stack and maybe some will use some concept of a frame pointer,
> and sometimes it might be helpful to bear all this in mind. But your details
> are far too specific.
>
No, they are general enough to cover most implementations.
santosh
> jacob navia said:
>
>> Recently K. Thompson asked me to specify what did I understand
>> with "stack frame". I think that it is important for people using the
>> language, that this important concept is clear, so I have produced
>> this post.
>
> Have you considered posting this in a newsgroup where it's relevant,
> such as, perhaps, comp.arch?
>
>> Obviously, there are some people here that live in some
>> special world where all those things do not exist.
>
> Well, there are many such worlds, of which comp.lang.c is one, yes.
> Others include rec.scuba, alt.folklore.urban, and sci.med.dentistry. I
> note that you did not post this article to those groups. Why post it
> to comp.lang.c?
IMO, it would be most appropriate in comp.compilers as the stack frame
is more a compiler artifact than anything else.
Richard Tobin
>>> since ALL programs running in the same operating system MUST agree
>>> as to what the frame pointer register is, if not CHAOS is surely the
>>> consequence.
>> That sounds unlikely.
>Try trashing the frame pointer then, and see what happens.
I can't be bothered to find out how to do that. Why not just tell us?
I wouldn't have expected the frame pointer to have any significance
outside the current process (except to a debugger), so I don't know
why "all programs running in the same operating system must agree".
-- Richard
--
:wq
jacob navia
Obvious, because all libraries in the OS must be called with specific
calling conventions and register usage agreements. All programs must
call the OS to do I/O. They must respect the OS ABI to call those basic
OS routines.
The OS libraries are used by ALL code that runs in that system
eventually, no matter what language the end user is using.
jacob navia
>
> IMO, it would be most appropriate in comp.compilers as the stack frame
> is more a compiler artifact than anything else.
>
Yes, compilers are an "artifact" of compiled languages. Obviously
you think that C is not one of them.
or what ???
Basic knowledge about compiler code generation is needed if you want
to be able to understand what is going on within your program.
Obviously it is not required, as you can drive a car for miles without
needing to know that it needs gas to run.
"According to my car user's manual, if I press this pedal the car
should move. It doesn't say ANYWHERE that gas is needed".
You have the same attitude here, like your big friend.
Why santosh?
You seem reasonable at times.
:-)
Richard Bos
> santosh wrote:
> >
> > IMO, it would be most appropriate in comp.compilers as the stack frame
> > is more a compiler artifact than anything else.
>
> Yes, compilers are an "artifact" of compiled languages. Obviously
> you think that C is not one of them.
>
> or what ???
You've never seen a C interpreter?
> Basic knowledge about compiler code generation is needed if you want
> to be able to understand what is going on within your program.
Bollocks. Knowledge of the _language_ is needed if you want to know what
your program does. If you want to know _how_ it does that, merely basic
knowledge about merely code generation is not nearly sufficient.
Richard
Richard Tobin
>> I wouldn't have expected the frame pointer to have any significance
>> outside the current process (except to a debugger), so I don't know
>> why "all programs running in the same operating system must agree".
>All programs must call the OS to do I/O. They must respect the OS ABI
>to call those basic OS routines.
Do any OS ABIs require the caller to take any care of the frame
pointer?
I just looked up the x86 call conventions. As far as I can see, the
calle saves and restores the frame pointer and does not use its old
value. So on these systems you do can use it for anyh purpose you
like.
[If you are called back by these libraries you will presumably have to
preserve the frame pointer, but that just restricts the functions
that you can pass in to it.]
>The OS libraries are used by ALL code that runs in that system
>eventually
No, this is certainly not true. I have used several languages that
just did system call instructions directly. The normal procedure
calling convention was irrelevant.
-- Richard
--
:wq
Antoninus Twink
> Recently K. Thompson asked me to specify what did I understand
> with "stack frame". I think that it is important for people using the
> language, that this important concept is clear, so I have produced
> this post.
>
> Obviously, there are some people here that live in some
> special world where all those things do not exist. They should stay
> there and ignore this thread. The same goes for all people that
> program in coffee machines and other primitive processors that
> do not have a stack pointer or enough registers to use a stack
> efficiently.
Jacob,
Your attempts to bring this group into touch with the real world are
admirable, but you must realize by now that they're doomed before they
start?
Noone here is prepared to give you a fair hearing, and noone cares about
stacks and registers or anything that might be tainted by association
with a real computer. The clc zealots aren't going to ignore a thread
just because they have nothing positive to contribute to it.
It's started already, but it's obvious that this thread is just going to
degenerate into a flame war, with HeathField and Thomson strutting,
preening and posturing, while their fawning acolytes (Santosh step
forward) try to cement their position in the Clique by sheer
obsequiousness.
This group just isn't the place for serious discussions about C.
jacob navia
> In article <fqgrl4$44a$1...@aioe.org>, jacob navia <ja...@nospam.org> wrote:
>
>>> I wouldn't have expected the frame pointer to have any significance
>>> outside the current process (except to a debugger), so I don't know
>>> why "all programs running in the same operating system must agree".
>
>> All programs must call the OS to do I/O. They must respect the OS ABI
>> to call those basic OS routines.
>
> Do any OS ABIs require the caller to take any care of the frame
> pointer?
>
Yes, the frame pointer should be preserved at all times.
> I just looked up the x86 call conventions. As far as I can see, the
> calle saves and restores the frame pointer and does not use its old
> value. So on these systems you do can use it for anyh purpose you
> like.
>
Yes, as I said in my message. Please read it again.
> [If you are called back by these libraries you will presumably have to
> preserve the frame pointer, but that just restricts the functions
> that you can pass in to it.]
>
>> The OS libraries are used by ALL code that runs in that system
>> eventually
>
> No, this is certainly not true. I have used several languages that
> just did system call instructions directly. The normal procedure
> calling convention was irrelevant.
Sure, but even using those "direct" calls, the frame
pointer must be preserved.
santosh
> santosh wrote:
>>
>> IMO, it would be most appropriate in comp.compilers as the stack
>> frame is more a compiler artifact than anything else.
>>
>
> Yes, compilers are an "artifact" of compiled languages. Obviously
> you think that C is not one of them.
Yes, but C itself doesn't specify that a stack frame is needed, nor the
details of it's setup and manipulation.
> or what ???
>
> Basic knowledge about compiler code generation is needed if you want
> to be able to understand what is going on within your program.
At the machine level. A semantic understanding is possible from just
knowing C and it's standard library. Obviously, it's not sufficient for
things like debugging, interfacing with other languages etc.
> Obviously it is not required, as you can drive a car for miles without
> needing to know that it needs gas to run.
>
> "According to my car user's manual, if I press this pedal the car
> should move. It doesn't say ANYWHERE that gas is needed".
>
> You have the same attitude here, like your big friend.
>
> Why santosh?
>
> You seem reasonable at times.
>
> :-)
I was not saying that knowledge of stack operations are not useful. I
was saying that it is not very topical for this group. Maybe you should
post to <news:comp.lang.asm.x86> or <news:comp.programming> or
<news:comp.compilers.lcc> etc.?
santosh
In point of fact, this isn't necessary under Linux x86.
Richard Tobin
>> Do any OS ABIs require the caller to take any care of the frame
>> pointer?
>Yes, the frame pointer should be preserved at all times.
But why?
>> I just looked up the x86 call conventions. As far as I can see, the
>> calle saves and restores the frame pointer and does not use its old
>> value. So on these systems you do can use it for anyh purpose you
>> like.
>Yes, as I said in my message. Please read it again.
You seem to be contradicting yourself. You say it must be preserved
at all times, and then you agree you can use it for any purpose.
Please explain.
>> No, this is certainly not true. I have used several languages that
>> just did system call instructions directly. The normal procedure
>> calling convention was irrelevant.
>Sure, but even using those "direct" calls, the frame
>pointer must be preserved.
Why? What happens if you don't?
-- Richard
--
:wq
Randy Howard
(in article <fqgv5o$u6o$2...@registered.motzarella.org>):
> jacob navia wrote:
>> Yes, the frame pointer should be preserved at all times.
[snip]
>>> No, this is certainly not true. I have used several languages that
>>> just did system call instructions directly. The normal procedure
>>> calling convention was irrelevant.
>>
>> Sure, but even using those "direct" calls, the frame
>> pointer must be preserved.
>
> In point of fact, this isn't necessary under Linux x86.
How did this -fomit-frame-pointer option make its way into my compiler?
BTW, it's not running on Linux either.
--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw
jacob navia
> In article <fqgubh$d4q$1...@aioe.org>, jacob navia <ja...@nospam.org> wrote:
>
>>> Do any OS ABIs require the caller to take any care of the frame
>>> pointer?
>
>> Yes, the frame pointer should be preserved at all times.
>
> But why?
>
>>> I just looked up the x86 call conventions. As far as I can see, the
>>> calle saves and restores the frame pointer and does not use its old
>>> value. So on these systems you do can use it for anyh purpose you
>>> like.
>
>> Yes, as I said in my message. Please read it again.
>
> You seem to be contradicting yourself. You say it must be preserved
> at all times, and then you agree you can use it for any purpose.
> Please explain.
>
A procedure can use any reserved register but the stack pointer
to any purpose anywhere, it needs only to save its value in
the stack, then restore it later. The value is preserved.
Obviously, if you do not preserve the stack pointer, many programs like
the debugger and others will no longer work, but in principle
your program will run without any problem.
>>> No, this is certainly not true. I have used several languages that
>>> just did system call instructions directly. The normal procedure
>>> calling convention was irrelevant.
>
>> Sure, but even using those "direct" calls, the frame
>> pointer must be preserved.
>
> Why? What happens if you don't?
If you do not preserve the stack pointer, you BREAK the
frame pointer chain, what means that you will destroy the possibility of
returning to the calling functions.
santosh
> On Mon, 3 Mar 2008 07:53:12 -0600, santosh wrote
> (in article <fqgv5o$u6o$2...@registered.motzarella.org>):
>
>> jacob navia wrote:
>>> Yes, the frame pointer should be preserved at all times.
>
> [snip]
>
>>>> No, this is certainly not true. I have used several languages that
>>>> just did system call instructions directly. The normal procedure
>>>> calling convention was irrelevant.
>>>
>>> Sure, but even using those "direct" calls, the frame
>>> pointer must be preserved.
>>
>> In point of fact, this isn't necessary under Linux x86.
>
> How did this -fomit-frame-pointer option make its way into my
> compiler?
That doesn't matter since you cannot make direct system calls in C
anyway.
> BTW, it's not running on Linux either.
Jacob was saying that the frame pointer (in his case: EBP) must be
preserved even for direct system calls. I was saying that it is not
necessary, at least under Linux/x86. In fact EBP can be used for a
parameter, if needed.
What gcc does within the program is just another point against what
Jacob is saying. He may have confused the frame pointer with the stack
pointer.
>
>
>
>
>
Richard Tobin
>A procedure can use any reserved register but the stack pointer
>to any purpose anywhere, it needs only to save its value in
>the stack, then restore it later. The value is preserved.
A procedure that's called from a procedure that expects the frame pointer
to be preserved has to preserve it. If your entire program consists
of functions that don't expect it to be preserved, you don't have to.
If your functions don't save the stack pointer but call library
functions that do, there is no problem. It's only if you are *called*
by functions that expect it to be preserved that you have to worry.
In short, you don't have to follow any convention about the frame
pointer in order to call library functions.
>>> Sure, but even using those "direct" calls, the frame
>>> pointer must be preserved.
>> Why? What happens if you don't?
>If you do not preserve the stack pointer, you BREAK the
>frame pointer chain, what means that you will destroy the possibility of
>returning to the calling functions.
How does this arise when doing a system call?
-- Richard
--
:wq
polas
As a C programmer who tends to read this newsgroup a lot more than
post to it I have found this topic very useful to me - without any
formal C training these basic underlying concepts are often missed...
so thanks for that definition - even if it is considered off topic by
some people or whatevern, it has helped me.
A very quick question (possibly slightly off topic - sorry if so)
apart from the stack pointers for functions, and the heap for dynamic
allocation, is there any other memory storage commonly used and
refered to?
Nick
santosh
<snip>
> A very quick question (possibly slightly off topic - sorry if so)
> apart from the stack pointers for functions, and the heap for dynamic
> allocation, is there any other memory storage commonly used and
> refered to?
Yes. Static objects are likely (though the standard says nothing about
this) to be stored in the program's data segment, which may or may not
be different from it's heap. Also read-only data might be stored in a
special write protected segment. You also forgot that a disk file is
also a storage unit. Many old DOS programs used to swap portions of
their image to the disk on the fly. Nowadays the OS does this instead.
Morris Dovey
> A very quick question (possibly slightly off topic - sorry if so)
> apart from the stack pointers for functions, and the heap for dynamic
> allocation, is there any other memory storage commonly used and
> refered to?
In embedded ("non-hosted") environments, it is not unusual for
I/O space to be mapped onto memory space. Mapped I/O may or may
not exhibit storage characteristics.
--
Morris Dovey
DeSoto Solar
DeSoto, Iowa USA
http://www.iedu.com/DeSoto
Chris Torek
>We can (conceptually) describe the stack frame as follows
>
>struct tagStackFrame {
> void *Previous;
> void *ThisFrame;
> char LocalStorage[];
>};
There is no need for a separate "this frame" pointer.
In any case, the more general term, which covers what a C compiler
*must* provide in effect, is "activation record". Any given
"activation record" -- whether it is on a stack or not -- contains
the "local storage" for the function, as you describe here.
If the activation record contains a single pointer to a previous
("I was called from") record, and new entries are only ever added
and removed from the same end, this forms a "stack-like" data
structure: a linked list in which the "most current" end is the
"top" of the stack, and previous entries are exposed by "popping
off" that top. (The top may well be at the lowest physical or
virtual address, or there may be no defined ordering. The
latter occurs when allocating activation records from a general
storage arena, a la malloc().)
>The "Next" member is a pointer to the previous function's stack frame,
"Previous" is of course a better name for this (and is the one
you used earlier). :-)
It is also true that many, perhaps even most, C compilers use a
hardware-provided stack to implement the stack-like data structure
containing the necessary activation records. These are "stack
frames". At least one compiler (for IBM machines) did historically
use a general free-store arena: there is no hardware-provided stack,
so the compiler can do whatever it likes. (As far as I know, these
systems still do this. I merely have not used them in more than
twenty years.)
It is better (in my opinion) to stick with the general term, i.e.,
"activation record", in comp.lang.c, since C compilers are not
required to use a hardware stack to implement the implied stack of
activation records. Moreover, systems that provide threads have
multiple sets of activation records, which may or may not form a
branching data structure of the sort sometimes referred to as a
"cactus stack". (You should think of a saguaro cactus here, the
stereotypical ones seen in Road-Runner-and-Coyote cartoons.) Of
course, A C implementation need not even use actual activation
records -- for instance, a magic one might use Divine Inspiration
to produce the correct results -- but it must behave *as if* it
used them. It does not, however, have to behave as though these
were allocated from a single hardware-provided stack, which is
good news for those that support threads.
You also mentioned VLAs (which are new in C99) here, and I have
a few more notes to make about this and your other extra notes:
>A function uses registers to do its calculations.
Most (I think; certainly at least "many") do. Not all, though.
The AT&T "Hobbit" architecture, for instance, had no registers of
that sort at all. Instead, it used "top of stack" for everything.
As a simplified example, if you wanted to add "x" and "y", instead
of loading the values into registers and doing an "add r1, r2",
you would push the values of x and y and then do an "add", which
pops the two top values from the value stack, adds them, and pushes
the result on the stack. Some Forth-oriented hardware does this
as well.
>Those register can be scratch registers, i.e. registers that can
>be used without having to save them, or they can be registers that
>need save before use, to preserve their value across function calls.
>The saved registers are part of the stack frame, even if I did not
>mention that above to keep things simple. They are restored before
>the current function exits.
One nice thing about stack-oriented architectures is that, since
there are no registers, there is never any need to save and
restore them. (Register-oriented hardware seems to have won the
CPU speed wars rather decisively, though. As we all know, the
most important thing for any computer is *how fast* it is, not
whether it gets the right answers. :-) )
>Another thing to be known is "alloca". This function allocates storage
>from the stack by decreasing the stack pointer. A function that calls
>alloca must do the popping of the current stack frame in a different
>manner since the current stack frame is "deformed" by alloca.
Indeed, an alloca() that adjusts the stack pointer wreaks havoc on
systems that use a hardware-provided stack and have a clever (but
not super-smart) compiler, since the clever compiler assumes that
only *it* ever does this stack-pointer adjustment. This is why
one *cannot* write this kind of alloca() with some compilers on
some machines -- which is, in turn, a reason (perhaps "the" reason)
why alloca() is not in Standard C: the guys writing the C standard
were aware of this problem. Instead, C99 provides "variable length
arrays":
>And yet another thing: in standard C, we can have objects whose size
>is allocated in local storage but whose exact size is unknown until
>run time. This is similar to alloca, and produces the same consequences.
Unlike alloca(), however, VLAs use special syntax. (A call to the
alloca() function looks like, and indeed sometimes is[%], an ordinary
function call.) By using special syntax, VLAs *force* the compiler
to participate in their creation. This participation means that
the compiler "knows" that the (hardware-provided) stack has been
altered at the point the VLA's storage is allocated, and can take
whatever actions are required to make it work. (This can be as
simple as allocating a "variable size stack frame" instead of a
"fixed size stack frame", along with all the consequences that go
with this: on MIPS machines, for instance, one marks the difference
in the debug table that goes with the binary, and uses a hardware
register as a frame pointer instead of using a "virtual" frame
pointer.)
[% I say "sometimes is" because some overly-clever compilers -- gcc
being one example -- will replace what *looks like* a call to
alloca() with appropriate machine code. This even goes as far
as switching from fixed-size to variable-size frames on machines
like the MIPS. In other words, "calling" alloca() does nothing
of the sort, and makes the compiler do the same work as for a
VLA.]
There is a subtle difference between "alloca-allocated storage"
and "VLA-allocated storage", in that the latter obeys block scope
rules:
void f(void) {
size_t size;
char *p;
for (size = 100; size < 10000; size++) {
char space[size];
... more code, possibly setting p = &space[i] ...
}
}
The function f() needs about 10 kbytes of space for its activation
record, since the largest the VLA named "space" will be is 10000.
However:
void g(void) {
size_t size;
char *p;
for (size = 100; size < 10000; size++) {
char *space = alloca(size);
... more code, possibly setting p = &space[i] ...
}
needs about 50 gigabytes (!), because each allocation must persist
for the duration of function g(). After the first iteration of
the loop in f(), the 100-element VLA named "space" is released
before the 101-element VLA named "space" is created (in the second
iteration of the loop); but in g(), the 100-element area allocated
by the first "call" to the alloca() pseduo-function must persist
when the 101-element area is allocated; both of those persist when
the 102-element area is allocated; and so on. (This matters if
you keep pointers to the "previous instance" around, e.g., if p[i]
might refer to a previous loop iteration.)
--
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: gmail (figure it out) http://web.torek.net/torek/index.html
polas
Thanks to both yourself and Santosh for answering my question - what
you have both said makes sense to me and has helped my understanding.
Nick
Keith Thompson
> santosh wrote:
>> IMO, it would be most appropriate in comp.compilers as the stack frame
>> is more a compiler artifact than anything else.
>
> Yes, compilers are an "artifact" of compiled languages. Obviously
> you think that C is not one of them.
>
> or what ???
You misunderstand. A "stack frame" is an artifict of the compiler.
> Basic knowledge about compiler code generation is needed if you want
> to be able to understand what is going on within your program.
Not really, though it doesn't hurt.
Knowledge of how to use a keyboard or similar input device is needed
to write programs, but we don't give touch-typing lessons here.
> Obviously it is not required, as you can drive a car for miles without
> needing to know that it needs gas to run.
>
> "According to my car user's manual, if I press this pedal the car
> should move. It doesn't say ANYWHERE that gas is needed".
And how does this metaphor apply? What terrible thing happens if you
don't know what a "stack frame" is?
[snip]
--
Keith Thompson (The_Other_Keith) <ks...@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Keith Thompson
[...]
> Obvious, because all libraries in the OS must be called with specific
> calling conventions and register usage agreements. All programs must
> call the OS to do I/O. They must respect the OS ABI to call those basic
> OS routines.
>
> The OS libraries are used by ALL code that runs in that system
> eventually, no matter what language the end user is using.
And there's the key phrase: "no matter what language".
Everything you described in the article that started this thread, to
the extent that it's applicable at all, is applicable to most or all
compiled programming languages. It has nothing to do with C. Why do
you insist on discussing it in comp.lang.c?
Keith Thompson
> In article <fqgksq$eja$1...@aioe.org>, jacob navia <ja...@nospam.org> wrote:
>>We can (conceptually) describe the stack frame as follows
>>
>>struct tagStackFrame {
>> void *Previous;
>> void *ThisFrame;
>> char LocalStorage[];
>>};
>
> There is no need for a separate "this frame" pointer.
And I'm not convinced there's a need for a Previous frame pointer.
Given a contiguous hardware-managed stack of the kind jacob assumes
(and to which he only barely acknowledges any possible alternatives),
a stack frame could simply keep track of its size. On exit from the
function, the value of the stack pointer is simply adjusted by that
size. Access to the contents of the previous stack frame is not
needed, since C doesn't have nested functions and cannot access local
objects in anything other than the current function. (Other
languages, such as Pascal, can do this, and therefore require somewhat
more elaborate stack layouts; in some environments it might make sense
to use such layouts for all compiled languages.)
> In any case, the more general term, which covers what a C compiler
> *must* provide in effect, is "activation record". Any given
> "activation record" -- whether it is on a stack or not -- contains
> the "local storage" for the function, as you describe here.
But the activation record for a function needn't be a single
fixed-size chunk, even ignoring VLAs. Local objects exist at block
scope, not at function scope. Given:
void func(void)
{
int x[1000];
{
int y[2000];
}
{
int z[4000];
}
}
We can assume that allocation for the outermost block is handled on
entry to the function, so the initial activation record must be at
least 1000 bytes -- but the space for y and z needn't be allocated
until those blocks are actually executed. (In a more complex
function, they might never be executed.)
A naive compiler might allocate a single 7000-byte activation record,
with separate storage for x, y, and z. <OT>gcc does this; oh,
well.</OT> A slightly more clever compiler might allocate a 5000-byte
activation record, with storage for y and z overlapped. A more
ambitious compiler might allocate just a 1000-byte activation record,
and allocate space for y and z only when their respective blocks are
entered.
I can't think of any good reason not to perform the simpler
optimization (the 5000-byte activation record). Allocating storage
for each block only when the block is entered (in effect treating each
block as an inline function) imposes some overhead, but could easily
be worthwhile if it saves substantial space. If there's a function
call in the block after the declaration of y, there's no reason to
waste space for storage for z during the execution of the called
function.
[snip]
Kaz Kylheku
> The stack frames are a linked list of this storage areas.
Not, for instance, when you are using gcc with -fomit-frame-pointer.
Then there is no linked list.
Full blown frames are useful for run-time introspection (debugging).
Otherwise, setting them up is nothing but a performance hit, because
it costs cycles and because dedicating a register to be a frame
pointer is a waste of a register.
What stack frame does is allows the local variables to be found
independently of the stack pointer, and it allows a reliable backtrace
to be computed so that the addresses of callers adn their local
variables can be found.
Without a frame pointer, different instruction sequences in a function
use different offsets relative to the stack pointer to find local
variables. Information like how large the stack frame is is implicit
in the generated code. To perform a backtrace, the backtrace routine
must analyze the code to determine how many bytes it will pop off the
stack. To know where the value of a local variable is, the debugger
has to look at the instruction pointer and know what the stack is
doing at that point in the code. This makes the debugger more complex
and less reliable.
Space reserved for local variables and a return address, but without
the debugging support, may still be called a stack frame, even without
the frame pointer and backward linkage. It's just not a ``full blown''
stack frame.
Keith Thompson
> Recently K. Thompson asked me to specify what did I understand with
> "stack frame". I think that it is important for people using the
> language, that this important concept is clear, so I have produced
> this post.
I also asked you to cite the standard to support your definition. Of
course the standard doesn't mention stacks, much less stack frames,
which was my real point.
[big snip]
> Another thing to be known is "alloca". This function allocates storage
> from the stack by decreasing the stack pointer. A function that calls
> alloca must do the popping of the current stack frame in a different
> manner since the current stack frame is "deformed" by alloca.
By decreasing the stack pointer? So you're not just assuming a
continuous stack, you're assuming that it grows in a particular
direction. What is your basis for this assumption? (Hint: "None" is
the correct answer.)
(Thanks to Chris Torek for posting the response I was going to post,
and probably doing a better job of it.)
Keith Thompson
> to be able to understand what is going on within your program.
What's even more important is an understanding of the difference
between a programming language (as defined by a standard) and a
particular implementation of that language. This is a distinction
that you insist in blurring.
jacob navia
> On Mar 3, 2:45 am, jacob navia <ja...@nospam.com> wrote:
>> The stack frames are a linked list of this storage areas.
>
> Not, for instance, when you are using gcc with -fomit-frame-pointer.
> Then there is no linked list.
>
Yes, there is. The stack pointer is implicitly the frame pointer.
As you explain later, the debug information fills the missing gaps so
that a debugger can walk the stack...
The linked list is conceptually there, no longer explicit but implicit
jacob navia
> jacob navia <ja...@nospam.com> writes:
> [...]
>> Basic knowledge about compiler code generation is needed if you want
>> to be able to understand what is going on within your program.
> [...]
>
> What's even more important is an understanding of the difference
> between a programming language (as defined by a standard) and a
> particular implementation of that language. This is a distinction
> that you insist in blurring.
>
Funny.
Where (yes WHERE) in my message did I mention something
implementation specific?
Morris Dovey
> Where (yes WHERE) in my message did I mention something
> implementation specific?
"stack"
Kaz Kylheku
> Kaz Kylheku wrote:
> > On Mar 3, 2:45 am, jacob navia <ja...@nospam.com> wrote:
> >> The stack frames are a linked list of this storage areas.
>
> > Not, for instance, when you are using gcc with -fomit-frame-pointer.
> > Then there is no linked list.
>
> Yes, there is. The stack pointer is implicitly the frame pointer.
>
> As you explain later, the debug information fills the missing gaps so
> that a debugger can walk the stack...
>
> The linked list is conceptually there, no longer explicit but implicit
By this definition, a sequence implemented as an array is still
``conceptually'' a linked list.
But it's actually an abstract sequence that's implemented as an array.
The concept is that of sequence.
``Linked list'' is the name given to a sequence data structure in
which we find a successor by chasing a pointer that is embedded in the
predecessor.
If we find the successor by displacing relative to the location of the
predecessor, we are not following a link.
jacob navia
Call it as you wish. It is not just like in an array since the offsets
to follow are NOT fixed displacements but displacements of different
sizes. Since we are following those links in the debug information,
in my opinion we are still following a linked chain. But if you think
you want it to be named otherwise (please propose a name) please do so.
What is important is to be clear of what we are talking about.
J. F. Lemaire
> jacob navia <ja...@nospam.com> writes:
> [...]
> Everything you described in the article that started this thread, to
> the extent that it's applicable at all, is applicable to most or all
> compiled programming languages. It has nothing to do with C. Why do
> you insist on discussing it in comp.lang.c?
Just a guess: because his signature contains a link to C-related
commercial software? In other words, it's called spam and there are
very effective protections against that.
--
Jean-François Lemaire
jacob navia
My compiler system can be freely downloaded at no charge.
And this since ten years.
But there people that insist on calling it commercial
since it is sucessful and I do have commercial customers
that interest themselves and pay for my software.
That is even worst for people like Mr lemaire
Where can I download ANY software from Mr lemaire?
What does he give for free to the community?
Michael Mair
> Recently K. Thompson asked me to specify what did I understand
> with "stack frame". I think that it is important for people using the
> language, that this important concept is clear, so I have produced
> this post.
>
> special world where all those things do not exist. They should stay
> there and ignore this thread. The same goes for all people that
> program in coffee machines and other primitive processors that
> do not have a stack pointer or enough registers to use a stack
> efficiently.
The above paragraph is contraproductive.
You could instead have asked people to contribute in a constructive
way and point out newsgroups where you also can have this checked.
Chris Torek and Kaz Kylheku already gave you valuable answers, so
I'll just go with the small stuff.
> ----------------------
> What is a stack frame?
> ---------------------
>
> Within a stack, each procedure builds a "stack frame", i.e. a fixed
> point within the stack, where storage for local variables is reserved.
I'll assume that you already told your gentle readers what a stack is.
The notion of "activation record" as explained by Chris should be
mentioned here before you go for the special stack frame.
If you want to stay generic, you can stay with activation records.
> The stack frames are a linked list of this storage areas.
^these
I'd rather go for "sequence" (see Kaz's reply) and mention linked
list as "common implementation".
> This builds
> the conceptual stack that the language needs.
Again, this assumes that you told the reader about "the stack".
> Each stack frame is
> linked to the previous one. A new stack frame is built when a
> procedure is entered, and it is popped from the stack of stack frames
> at the procedure exit.
This is not exactly in keeping with what you told above about the
linked list. Mixing stack as data structure and "the stack" will
not necessarily help your readers.
> The "main" function has the first (visible) frame, and each stack
> frame built in one of the functions called after "main" started is
> linked to that stack frame. This makes it possible for debuggers
> and other tools to "walk the stack" of called procedures.
>
> We can (conceptually) describe the stack frame as follows
>
> struct tagStackFrame {
> void *Previous;
> void *ThisFrame;
> char LocalStorage[];
For CLC, you may want to have "unsigned char".
> };
>
> The "Next" member is a pointer to the previous function's stack frame,
^Previous
> the "ThisFrame" pointer points to the current stack frame, and the
> Local storage is made out of different variables that a function
> declares.
What is for
struct tagStackFrame S;
the relationship between S and S.ThisFrame?
> We can imagine that the local storage of deeper nested
> blocks is added to the function's local storage, even if it is not
> visible (i.e. can't be accessed) after its scope disappears.
In this context, a quick mention of the implications of "goto"
and weak variants thereof at the end may be interesting.
>
> Building the stack frame (Prologue)
> ------------------------
>
> The first thing to do to build a stack frame is then, to save in the
> "Previous" slot, the value of the current stack frame pointer.
> Normally, this is a dedicated register. For instance, the power PC
> version of lcc-win uses register 31. This register is normally
> defined by the operating system ABI (Application Binary Interface)
> since ALL programs running in the same operating system MUST agree
> as to what the frame pointer register is, if not CHAOS is surely the
> consequence.
I think you are too vague here.
I'd call it "common practice" to assuage all voices telling you
of special cases and explain the advantages of all programmes (and
consequently, all implementations) holding to the same convention.
"Unending CHAOS will ensue" is not very convincing, IMO.
>
> After saving the current FP (or Frame Pointer) we copy the current
> value of the stack pointer into the frame pointer, to establish a new
> stack frame from this stack position on. We fill then, the "ThisFrame"
> slot of our structure, and lastly, we subtract from the frame pointer
> the amount of space needed by the function's local variables, our
> "Local storage" member.
>
> There exist MANY variation of this scheme. Some optimizing compilers
> save themselves the trouble of having a different register than the
> stack pointer to build a stack frame, and just use the stack pointer to
> address local variables. Conceptually however, nothing changes.
>
> Popping the stack frame (Epilogue)
> -----------------------
>
> A function must restore the previous stack frame before leaving the
> scene.
Why? What is the consequence if it does not? (Please not just "chaos")
> This is done in the reverse order of the previous actions. The
> space allocated for local variables is released by adjusting the stack
> pointer, the previous value of the stack frame is popped from the stack,
> and the function can now return.
>
> Other stuff
> -----------
I'd call it Miscellaneous or Specialities in order to sound sufficiently
important ;-)
>
> A function uses registers to do its calculations. Those register can be
^registers
> scratch registers, i.e. registers that can be used without having to
> save them, or they can be registers that need save before use, to
> preserve their value across function calls. The saved registers are part
> of the stack frame, even if I did not mention that above to keep things
> simple. They are restored before the current function exits.
>
> Another thing to be known is "alloca". This function allocates storage
> from the stack by decreasing the stack pointer. A function that calls
> alloca must do the popping of the current stack frame in a different
> manner since the current stack frame is "deformed" by alloca.
>
> And yet another thing: in standard C, we can have objects whose size
> is allocated in local storage but whose exact size is unknown until
> run time. This is similar to alloca, and produces the same consequences.
See Chris' remarks on alloca() vs. VLAs.
As mentioned above, something on goto might be interesting around here.
Maybe setjmp()/longjmp(), too.
Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
jacob navia
>>jn:
>> Each stack frame is
>> linked to the previous one. A new stack frame is built when a
>> procedure is entered, and it is popped from the stack of stack frames
>> at the procedure exit.
>
> This is not exactly in keeping with what you told above about the
> linked list. Mixing stack as data structure and "the stack" will
> not necessarily help your readers.
>
At the procedure prologue, the new stack frame is pushed into
the stack of existing stack frames. At procedure exit time,
(epilogue) the pushed frame is popped from the stack of stack
frames.
That is quite clear.
>> The "main" function has the first (visible) frame, and each stack
>> frame built in one of the functions called after "main" started is
>> linked to that stack frame. This makes it possible for debuggers
>> and other tools to "walk the stack" of called procedures.
>>
>> We can (conceptually) describe the stack frame as follows
>>
>> struct tagStackFrame {
>> void *Previous;
>> void *ThisFrame;
>> char LocalStorage[];
>
> For CLC, you may want to have "unsigned char".
Mmm maybe but why?
>
>> };
>>
>> The "Next" member is a pointer to the previous function's stack frame,
> ^Previous
>
>> the "ThisFrame" pointer points to the current stack frame, and the
>> Local storage is made out of different variables that a function
>> declares.
>
> What is for
> struct tagStackFrame S;
> the relationship between S and S.ThisFrame?
>
The access to the LocalStorage member is done using offsets from the
"This frame" pointer.
>> We can imagine that the local storage of deeper nested
>> blocks is added to the function's local storage, even if it is not
>> visible (i.e. can't be accessed) after its scope disappears.
>
> In this context, a quick mention of the implications of "goto"
> and weak variants thereof at the end may be interesting.
>
I mentioned some of the problems, but not all of them. Yes, in this
context should come the goto side effects, etc.
I will post several other articles about this stack theme, so I will
expand this later.
CBFalconer
> Keith Thompson wrote:
>> jacob navia <ja...@nospam.com> writes:
>>
>> [...]
>>
>>> Basic knowledge about compiler code generation is needed if you
>>> want to be able to understand what is going on within your
>>> program.
>> [...]
>>
>> What's even more important is an understanding of the difference
>> between a programming language (as defined by a standard) and a
>> particular implementation of that language. This is a
>> distinction that you insist in blurring.
>
> Funny. Where (yes WHERE) in my message did I mention something
> implementation specific?
Right here:
"Within a stack, each procedure builds a "stack frame", i.e. a
fixed point within the stack, where storage for local variables
is reserved."
Which showed up at the beginning of your off-topic post.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
--
Posted via a free Usenet account from http://www.teranews.com
CBFalconer
> santosh wrote:
>
>> IMO, it would be most appropriate in comp.compilers as the stack
>> frame is more a compiler artifact than anything else.
>
> Yes, compilers are an "artifact" of compiled languages. Obviously
> you think that C is not one of them.
>
> or what ???
The point is that this is not suitable for c.l.c.
comp.compilers.lcc would be suitable, as would other suggestions
that have been made. The c language implementation MAY use a
stack, but does not have to. Therefore stacks (except actual code
to implement one) are off-topic on c.l.c. I believe you have had
this explained to you earlier. In fact, several times.
Richard
> jacob navia wrote:
>> santosh wrote:
>>
>>> IMO, it would be most appropriate in comp.compilers as the stack
>>> frame is more a compiler artifact than anything else.
>>
>> Yes, compilers are an "artifact" of compiled languages. Obviously
>> you think that C is not one of them.
>>
>> or what ???
>
> The point is that this is not suitable for c.l.c.
> comp.compilers.lcc would be suitable, as would other suggestions
> that have been made. The c language implementation MAY use a
> stack, but does not have to. Therefore stacks (except actual code
> to implement one) are off-topic on c.l.c. I believe you have had
> this explained to you earlier. In fact, several times.
Stacks or the "concept" of stacks are important for programmers and give
something concrete to think of when discussing automatic variables.
Does your pedantry know no bounds?
Kenny McCormack
Keith Thompson
> Keith Thompson wrote:
>> jacob navia <ja...@nospam.com> writes:
>> [...]
>>> Basic knowledge about compiler code generation is needed if you want
>>> to be able to understand what is going on within your program.
>> [...]
>>
>> What's even more important is an understanding of the difference
>> between a programming language (as defined by a standard) and a
>> particular implementation of that language. This is a distinction
>> that you insist in blurring.
>
> Funny.
>
> Where (yes WHERE) in my message did I mention something
> implementation specific?
Seriously? Practically all of it was implementation specific. (That
doesn't mean it's specific to any one particular implementation.)
Equally to the point, apart from briefly using C to describe the
representation of a stack frame, it really had no more to do with C
than with any other compiled language.
Richard Bos
> J. F. Lemaire wrote:
> > commercial software? In other words, it's called spam and there are
> > very effective protections against that.
>
> My compiler system can be freely downloaded at no charge.
Spam is related to the frequency of the advertisement, not to the
average financial proceeds thereof. By that measure alone, your posts
_would_ be spam. But IMO, your posting your URL _in your sig_ is not
spam. That (amongst others) is what sigs are for, after all. What
irritates me about this whole thread, and most others you start, is that
they're massively system-specific, and you seem too thick to (want to)
realise this.
Richard
Nick Keighley
> Kaz Kylheku wrote:
> > On Mar 3, 2:45 am, jacob navia <ja...@nospam.com> wrote:
> >> The stack frames are a linked list of this storage areas.
>
> > Not, for instance, when you are using gcc with -fomit-frame-pointer.
> > Then there is no linked list.
>
> Yes, there is. The stack pointer is implicitly the frame pointer.
>
> As you explain later, the debug information fills the missing gaps so
> that a debugger can walk the stack...
>
> The linked list is conceptually there, no longer explicit but implicit
'Oh, that was easy' says Jacob, and for an encore goes on to prove
that black is white and gets himself killed on the next zebra
crossing.
--
Nick Keighley
Keith Thompson
There's an unfortunate tendency to use the word "spam" for "any Usenet
posting that annoys me".
The generally accepted definition of Usenet spam is substantially
identical articles posted repeatedly. There's a formula (look up
"Breidbart index") used to determine whether a given spam is bad
enough to warrant third-party cancellation.
Note that it has nothing to do with whether the content is commercial.
Content is irrelevant to the question of whether something is spam;
posting the Gettysburg Address 1000 times, and it's spam.
jacob's posts are not spam by any reasonable definition, and saying
that they are merely weakens the term. and makes the fight against
*real* spam marginally more difficult.
The problem with some of jacob's posts is that they're off-topic.
Personally, I'm not particularly bothered by any partly commercial
nature of his posts. His statement that lcc-win can be freely
downloaded is irrelevant because it's an answer to an irrelevant
charge. If lcc-win were completely free (GPLed, public domain, or
whatever flavor of "free" floats your boat), I would find his advocacy
*here* of its non-standard extensions equally annoying. And of course
he can put whatever he likes in his signature. In his off-topic post
that started this thread, I don't think he even mentioned lcc-win.
Richard Heathfield
<snip>
> In his off-topic post
> that started this thread, I don't think he even mentioned lcc-win.
That's only because your eyes started to glaze over. You won't be terribly
surprised, I suspect, to discover that you are mistaken on this occasion.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
J. F. Lemaire
> r...@hoekstra-uitgeverij.nl (Richard Bos) writes:
>> jacob navia <ja...@nospam.com> wrote:
>>> J. F. Lemaire wrote:
>>> > commercial software? In other words, it's called spam and there
>>> > are very effective protections against that.
>>>
>>> My compiler system can be freely downloaded at no charge.
>>
>> Spam is related to the frequency of the advertisement, not to the
>> average financial proceeds thereof. By that measure alone, your posts
>> _would_ be spam. But IMO, your posting your URL _in your sig_ is not
>> spam. That (amongst others) is what sigs are for, after all. What
>> irritates me about this whole thread, and most others you start, is
>> that they're massively system-specific, and you seem too thick to
>> (want to) realise this.
>
> There's an unfortunate tendency to use the word "spam" for "any Usenet
> posting that annoys me".
I should probably not have used that term in the first place. However, I
suppose the real question is *why* jacob is posting in this newsgroup.
Some may think that he is posting messages to participate in
discussions of some aspects of C. I don't. I think he is posting merely
as a means to attract attention to his commercial software, either
through his signature, which may be acceptable or, which is more
hypocritical, by making more or less subtle mentions of the said
software "just in passing".
And, you are right, this can not be called spam -- even though it is
certainly unwanted and tends to come in bulk. I personally call this
advertisement and, if I'm not mistaken, advertisement is only accepted
on Usenet if it is both nonintrusive and announced as such.
I am personally not annoyed by jacob's messages since I killfiled him
months ago. But I am annoyed by intelligent and knowledgeable people
who keep following him in his nonsensical rants, giving him credit in
the process, and unknowingly helping him maintain his advertisement
enterprise.
--
Jean-François Lemaire
santosh
<snip>
> I should probably not have used that term in the first place. However,
> I suppose the real question is *why* jacob is posting in this
> newsgroup. Some may think that he is posting messages to participate
> in discussions of some aspects of C. I don't. I think he is posting
> merely as a means to attract attention to his commercial software,
> either through his signature, which may be acceptable or, which is
> more hypocritical, by making more or less subtle mentions of the said
> software "just in passing".
>
> And, you are right, this can not be called spam -- even though it is
> certainly unwanted and tends to come in bulk. I personally call this
> advertisement and, if I'm not mistaken, advertisement is only accepted
> on Usenet if it is both nonintrusive and announced as such.
>
> I am personally not annoyed by jacob's messages since I killfiled him
> months ago. But I am annoyed by intelligent and knowledgeable people
> who keep following him in his nonsensical rants, giving him credit in
> the process, and unknowingly helping him maintain his advertisement
> enterprise.
Well, IMO, Jacob's messages may be frequently off-topic (which is their
main objection, from nearly all who respond to him), but are not
nonsensical rants.
Also I personally don't mind his "just in passing" advertisement of his
compiler. Many posters advertise their products too via their
signatures. As long as he doesn't repeatedly mention lcc-win32 it is
fine, IMO.
I would hope that everyone who participates in this group are mature
enough to try out and choose whatever compiler that best suits them,
advertisements notwithstanding.
Keith Thompson
> Keith Thompson said:
>
> <snip>
>
>> In his off-topic post
>> that started this thread, I don't think he even mentioned lcc-win.
>
> That's only because your eyes started to glaze over. You won't be terribly
> surprised, I suspect, to discover that you are mistaken on this occasion.
You're right, but he mentions it only briefly as a concrete example of
a more general concept. If the article as a whole had been topical,
his mention of lcc-win wouldn't have been a problem (at least not for
me).
Richard
> J. F. Lemaire wrote:
>
> <snip>
>
>> I should probably not have used that term in the first place. However,
>> I suppose the real question is *why* jacob is posting in this
>> newsgroup. Some may think that he is posting messages to participate
>> in discussions of some aspects of C. I don't. I think he is posting
>> merely as a means to attract attention to his commercial software,
>> either through his signature, which may be acceptable or, which is
>> more hypocritical, by making more or less subtle mentions of the said
>> software "just in passing".
>>
>> And, you are right, this can not be called spam -- even though it is
>> certainly unwanted and tends to come in bulk. I personally call this
>> advertisement and, if I'm not mistaken, advertisement is only accepted
>> on Usenet if it is both nonintrusive and announced as such.
>>
>> I am personally not annoyed by jacob's messages since I killfiled him
>> months ago. But I am annoyed by intelligent and knowledgeable people
>> who keep following him in his nonsensical rants, giving him credit in
>> the process, and unknowingly helping him maintain his advertisement
>> enterprise.
>
> Well, IMO, Jacob's messages may be frequently off-topic (which is their
> main objection, from nearly all who respond to him), but are not
> nonsensical rants.
Of course they are not, as any "non clique member" knows. It's just
Heathfield being Heathfield and his unhealthy disposition towards
Jacob. Any why? Because Jacob puts Heathfield in his place. Heathfield
is interested in one opinion - and that is his own. A shame as his
knowledge of C coupled with a less big headed and preposterously huge
self regard would be much more useful to all. The recent thread about
rounding numbers really did it for me. RH purposely misrepresented
everything in order to put Jacob down and elevate himself. It happens
too much.
The group is comp.lang.c and is therefore open to C programmers. And C
programmers in the real world rarely need "ISO C" : they are looking for
like minded folk to chew the cud with and this is the only place for
that on usenet. I for one am glad to see people like Jacob stick up for
common sense. Why shouldnt someone ask here what C programmers prefer to
use as an editor? Why shouldn't they ask for opinions on compilers? Who
are these self appointed guardians? And then we have guys saying "try
google". FFS? Why are they here? What is the line between asking
sentient human beings a question and using google? Who makes these
limits? I await the "we voted on it" rubbish. The only people who voted
were the groups self appointed Gods. Nearly everyone else more moderate
has gone away. The difference between c.l.c is palpable. I for one am
glad to see Kenny haunt these arrogant fools because they are guilty of
taking themselves far too seriously. Just look at the amount of times
they slag someone off only to find they were wrong. They just can not
wait to shout "Off topic!!!!!!!!". Does that "Default User" Brian do
anything but that? All he seems to do is kiss Heathfield's arse and tell
people off for top posting or posting OT. How sad can one individual be?
Half the big dogs in this group either have no social life or they
haven't worked out the basics of killfiles or thread scoring. Not
interested? Don't read it. It really is that simple.
>
> Also I personally don't mind his "just in passing" advertisement of his
> compiler. Many posters advertise their products too via their
> signatures. As long as he doesn't repeatedly mention lcc-win32 it is
> fine, IMO.
CBF is even asking for jobs in his! Well, in ONE of his two signatures
anyway.
>
> I would hope that everyone who participates in this group are mature
> enough to try out and choose whatever compiler that best suits them,
> advertisements notwithstanding.
Exactly.
Or should I say "Indeed".
Chris Torek
>> There is no need for a separate "this frame" pointer [within an
activation record].
In article <8763w3z...@kvetch.smov.org>
Keith Thompson <ks...@mib.org> wrote:
>And I'm not convinced there's a need for a Previous frame pointer.
Indeed, *if* all activation records are recorded in a single
contiguous array, the "previous" for any given entry is simply
"just before the current entry":
>Given a contiguous hardware-managed stack of the kind jacob assumes
>(and to which he only barely acknowledges any possible alternatives),
>a stack frame could simply keep track of its size. On exit from the
>function, the value of the stack pointer is simply adjusted by that
>size.
This is in fact what is done on a number of systems.
>Access to the contents of the previous stack frame is not
>needed, since C doesn't have nested functions and cannot access local
>objects in anything other than the current function. (Other
>languages, such as Pascal, can do this, and therefore require somewhat
>more elaborate stack layouts; in some environments it might make sense
>to use such layouts for all compiled languages.)
Right -- and this is probably the main reason why the general
"activation record" data structure, as used in compiler circles,
includes a "previous" pointer. (In addition, "pointer" is just
another abstraction here: even if activation records are not
contiguous, one can use an array index instead of a pointer, if
they are all stored in a single array.)
>>[example of large arrays with block scope, where a total of
5000 bytes is all that is needed, even though several
compilers use 7000 bytes and thus keep both objects "live"
at all times within the function, even though one or the
other *could* "go dead" at any time outside its block.]
>I can't think of any good reason not to perform the simpler
>[scope based] optimization (the 5000-byte activation record).
There is one (not so good) reason having to do with debugging,
particularly if the debugger is not able to deal with overlapping
storage (which would give it problems with unions too, but perhaps
the debug format allows overlap *only* for union data types, and
the compiler-writer was unwilling to construct an "internal union
purely to keep the debugger happy).
>Allocating storage for each block only when the block is entered
>(in effect treating each block as an inline function) imposes
>some overhead, but could easily be worthwhile if it saves
>substantial space.
Yes. I assume some compilers have flags to control this sort of
thing, though I have not personally used one.
--
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: gmail (figure it out) http://web.torek.net/torek/index.html
jacob navia
>
> I should probably not have used that term in the first place. However, I
> suppose the real question is *why* jacob is posting in this newsgroup.
> Some may think that he is posting messages to participate in
> discussions of some aspects of C.
Well, that is obviously my intention. The messages I post are for
discussion and I respect other people's views even if I do not
agree with them.
> I don't. I think he is posting merely
> as a means to attract attention to his commercial software, either
> through his signature, which may be acceptable or, which is more
> hypocritical, by making more or less subtle mentions of the said
> software "just in passing".
>
Yes. Sure. My software is SO commercial that you can download it
for free. Can't you see how ridiculous this is?
You can't post something related to the discussion? You think that
a stack frame is a useless concept?
SAY IT!
Argue, discuss. Stop your speculation about my ulterior motives.
> And, you are right, this can not be called spam -- even though it is
> certainly unwanted and tends to come in bulk. I personally call this
> advertisement and, if I'm not mistaken, advertisement is only accepted
> on Usenet if it is both nonintrusive and announced as such.
>
Advertisements of stack frames?
You need to go to a doctor.
> I am personally not annoyed by jacob's messages since I killfiled him
> months ago.
Well you have a bug in your killfile then. Unable to do anything
correctly, you can't even setup a kill file.
Dik T. Winter
...
> But the activation record for a function needn't be a single
> fixed-size chunk, even ignoring VLAs. Local objects exist at block
> scope, not at function scope. Given:
>
> void func(void)
> {
> int x[1000];
> {
> int y[2000];
> }
> {
> int z[4000];
> }
> }
...
> A naive compiler might allocate a single 7000-byte activation record,
> with separate storage for x, y, and z. <OT>gcc does this; oh,
> well.</OT> A slightly more clever compiler might allocate a 5000-byte
> activation record, with storage for y and z overlapped. A more
> ambitious compiler might allocate just a 1000-byte activation record,
> and allocate space for y and z only when their respective blocks are
> entered.
But there may be good reasons to go with the allocation of 5000 bytes.
One reason might be that there are no simple methods to manipulate the
stack pointer directly, e.g., when it is only manipulated by an "enter"
instruction that manipulates both stack and frame pointer that are
invisible for the program.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Keith Thompson
> In article <8763w3z...@kvetch.smov.org> Keith Thompson
> <ks...@mib.org> writes:
> ...
> > But the activation record for a function needn't be a single
> > fixed-size chunk, even ignoring VLAs. Local objects exist at block
> > scope, not at function scope. Given:
> >
> > void func(void)
> > {
> > int x[1000];
> > {
> > int y[2000];
> > }
> > {
> > int z[4000];
> > }
> > }
> ...
> > A naive compiler might allocate a single 7000-byte activation record,
> > with separate storage for x, y, and z. <OT>gcc does this; oh,
> > well.</OT> A slightly more clever compiler might allocate a 5000-byte
> > activation record, with storage for y and z overlapped. A more
> > ambitious compiler might allocate just a 1000-byte activation record,
> > and allocate space for y and z only when their respective blocks are
> > entered.
>
> But there may be good reasons to go with the allocation of 5000 bytes.
> One reason might be that there are no simple methods to manipulate the
> stack pointer directly, e.g., when it is only manipulated by an "enter"
> instruction that manipulates both stack and frame pointer that are
> invisible for the program.
Hmm. Manipulating the stack would have to be impossible, not just to
the C program, but to the machine code generated by the compiler.
That seems implausibly strict, and it would make VLAs impossible to
implement other than by using malloc or some near equivalent.
Such an architecture is certainly possible, but I'd be surprised if it
actually existed.
To get back to terms relevant to standard C, suppose there's a
function call in the block that declares y. I'd be surprised to see
an implementation where, for fundamental architectural reasons, space
has to be allocated for z while that function call is being executed.
This could be *extremely* wasteful in the case of deep recursion,
where you could have multiple useless copies of z.
On the other hand, some compilers probably do allocate space for z
just because it's easier, or because allocating and deallocating
block-local objects carries some overhead. And there's probably not a
whole lot of code that would benefit greatly from the optimization of
delaying the allocation; most programmers probably don't declare large
block-local variables in the expectation that it will save space
outside the block.
There's probably something of a vicious circle between compilers not
doing the optimization and programmers not writing code that could
take advantage of it.
Neil
> Keith Thompson wrote:
>> jacob navia <ja...@nospam.com> writes:
>> [...]
>>> Basic knowledge about compiler code generation is needed if you want
>>> to be able to understand what is going on within your program.
>> [...]
>>
>> What's even more important is an understanding of the difference
>> between a programming language (as defined by a standard) and a
>> particular implementation of that language. This is a distinction
>> that you insist in blurring.
>>
>
> Funny.
>
> Where (yes WHERE) in my message did I mention something
> implementation specific?
>
>
>
This would assume the CPUs with no Frame pointers or Parameter Stack
could not run C. But they can, and do. While what you show is widely
used on larger CPUs it is not a requirement to do it that way. The C
spec does not care.
Antoninus Twink
A great post that says it all, really.
It should be added to the CLC FAQ:
Q. What the hell's up with CLC?
A. As above.
Dik T. Winter
> "Dik T. Winter" <Dik.W...@cwi.nl> writes:
> > But there may be good reasons to go with the allocation of 5000 bytes.
> > One reason might be that there are no simple methods to manipulate the
> > stack pointer directly, e.g., when it is only manipulated by an "enter"
> > instruction that manipulates both stack and frame pointer that are
> > invisible for the program.
>
> Hmm. Manipulating the stack would have to be impossible, not just to
> the C program, but to the machine code generated by the compiler.
> That seems implausibly strict, and it would make VLAs impossible to
> implement other than by using malloc or some near equivalent.
I have used an Algol 68 compiler that did put nearly everything on the
heap for efficiency. So it is not so very bad.
> Such an architecture is certainly possible, but I'd be surprised if it
> actually existed.
If I remember right, the NS 32000.
Keith Thompson
> In article <87lk4xu...@kvetch.smov.org> Keith Thompson
> <ks...@mib.org> writes:
> > Such an architecture is certainly possible, but I'd be surprised if it
> > actually existed.
>
> If I remember right, the NS 32000.
I am duly surprised.
J. J. Farrell
> Recently K. Thompson asked me to specify what did I understand
> with "stack frame". I think that it is important for people using the
Why? One of the major advantages of using a language like C is that the
programmer doesn't need to know anything about things like stack frames.
Geoff
wrote:
Huh? What? C insulates you from the machine? Not hardly.
Not understanding how local variables are stored in your
implementation of C leads to problems like buffer overflows and
smashed-stack exploits along with "bad" practices that become
implementation dependent bugs.
Why are strcat, strcpy, gets, scanf, sprintf, sscanf and fopen to name
but a few standard library functions unsafe? If you cannot answer
these questions you should not be programming in C. Go back to your
Java sandbox.
Ian Collins
> On Sun, 09 Mar 2008 22:49:49 +0000, "J. J. Farrell" <j...@bcs.org.uk>
> wrote:
>
>> jacob navia wrote:
>>> Recently K. Thompson asked me to specify what did I understand
>>> with "stack frame". I think that it is important for people using the
>>> language, that this important concept is clear, ...
>> Why? One of the major advantages of using a language like C is that the
>> programmer doesn't need to know anything about things like stack frames.
>
> Huh? What? C insulates you from the machine? Not hardly.
>
> Not understanding how local variables are stored in your
> implementation of C leads to problems like buffer overflows and
> smashed-stack exploits along with "bad" practices that become
> implementation dependent bugs.
>
Not understanding how to use the standard library functions correctly
leads to the above. Whether your implementation stores local variables
on a stack or somewhere else, local storage is still a finite resource.
Where they go isn't important.
--
Ian Collins.
Charlton Wilbur
G> Not understanding how local variables are stored in your
G> implementation of C leads to problems like buffer overflows and
G> smashed-stack exploits along with "bad" practices that become
G> implementation dependent bugs.
Hardly; buffer overflows happen because the programmer creates a
buffer of a certain size and then tries to write past its extents.
This is, in terms of the abstract machine, "undefined behavior." Good
programmers will not write programs that result in undefined behavior.
G> Why are strcat, strcpy, gets, scanf, sprintf, sscanf and fopen
G> to name but a few standard library functions unsafe? If you
G> cannot answer these questions you should not be programming in
G> C. Go back to your Java sandbox.
And the reason they are unsafe is not because of their implementation
but because some of the ways the C abstract machine works mean that
the responsibility for their correct operation has to fall on the
programmer. They are "unsafe" in that using them carelessly will
result in undefined behavior -- which on certain implementations may
include such things as "smashing the stack" and "buffer overruns."
Charlton
--
Charlton Wilbur
cwi...@chromatico.net
Richard Tobin
Geoff <ge...@invalid.invalid> wrote:
>Not understanding how local variables are stored in your
>implementation of C leads to problems like buffer overflows and
>smashed-stack exploits
How?
Just exactly what do you do differently as a result of understanding
how local variables are stored?
-- Richard
--
:wq
Richard
Nonsense.
In the REAL world, understanding how these things work will enable you
to use a real debugger to spot such overflows.
All programmers make mistakes, regardless of how well they know the
standard functions.
Richard Tobin
Richard <de...@gmail.com> wrote:
>>> Not understanding how local variables are stored in your
>>> implementation of C leads to problems like buffer overflows and
>>> smashed-stack exploits along with "bad" practices that become
>>> implementation dependent bugs.
[...]
>Nonsense.
>
>In the REAL world, understanding how these things work will enable you
>to use a real debugger to spot such overflows.
Yes, but that wasn't the claim. Understanding the implementation of
local variables may help you *find* this kind of bug, but it's not the
lack of understanding that "leads to" these problems. The mistakes
that cause buffer overflows on the stack are the same ones that cause
buffer overflows elsewhere.
The only reason for mentioning "stack" and "buffer overflow" in the
same breath is that the stack is the easiest place to exploit the
mistake.
-- Richard
--
:wq
Richard
> In article <fr4ccm$v6j$2...@registered.motzarella.org>,
> Richard <de...@gmail.com> wrote:
>
>>>> Not understanding how local variables are stored in your
>>>> implementation of C leads to problems like buffer overflows and
>>>> smashed-stack exploits along with "bad" practices that become
>>>> implementation dependent bugs.
>
> [...]
>
>>Nonsense.
>>
>>In the REAL world, understanding how these things work will enable you
>>to use a real debugger to spot such overflows.
>
> Yes, but that wasn't the claim. Understanding the implementation of
> local variables may help you *find* this kind of bug, but it's not the
> lack of understanding that "leads to" these problems. The mistakes
> that cause buffer overflows on the stack are the same ones that cause
> buffer overflows elsewhere.
Agreed. But 99% of systems do indeed use stacks and the "buffer
overflows elsewhere" are simply of no concern to the great majority of C
programmers.
Bottom line is this : learn how stacks work and your debugging skills
will be much better on those architectures with stacks (read just about
all platforms).
Ian Collins
> ric...@cogsci.ed.ac.uk (Richard Tobin) writes:
>
>> In article <fr4ccm$v6j$2...@registered.motzarella.org>,
>> Richard <de...@gmail.com> wrote:
>>
>>>>> Not understanding how local variables are stored in your
>>>>> implementation of C leads to problems like buffer overflows and
>>>>> smashed-stack exploits along with "bad" practices that become
>>>>> implementation dependent bugs.
>> [...]
>>
>>> Nonsense.
>>>
>>> In the REAL world, understanding how these things work will enable you
>>> to use a real debugger to spot such overflows.
>> Yes, but that wasn't the claim. Understanding the implementation of
>> local variables may help you *find* this kind of bug, but it's not the
>> lack of understanding that "leads to" these problems. The mistakes
>> that cause buffer overflows on the stack are the same ones that cause
>> buffer overflows elsewhere.
>
> Agreed. But 99% of systems do indeed use stacks and the "buffer
> overflows elsewhere" are simply of no concern to the great majority of C
> programmers.
>
> Bottom line is this : learn how stacks work and your debugging skills
> will be much better on those architectures with stacks (read just about
> all platforms).
>
Knowing how stacks work has little bearing on detecting buffer overflow.
Learning to spot the symptoms of overflowing an automatic variable
does, no matter where they might be allocated.
--
Ian Collins.
Richard
> Richard wrote:
>> ric...@cogsci.ed.ac.uk (Richard Tobin) writes:
>>
>>> In article <fr4ccm$v6j$2...@registered.motzarella.org>,
>>> Richard <de...@gmail.com> wrote:
>>>
>>>>>> Not understanding how local variables are stored in your
>>>>>> implementation of C leads to problems like buffer overflows and
>>>>>> smashed-stack exploits along with "bad" practices that become
>>>>>> implementation dependent bugs.
>>> [...]
>>>
>>>> Nonsense.
>>>>
>>>> In the REAL world, understanding how these things work will enable you
>>>> to use a real debugger to spot such overflows.
>>> Yes, but that wasn't the claim. Understanding the implementation of
>>> local variables may help you *find* this kind of bug, but it's not the
>>> lack of understanding that "leads to" these problems. The mistakes
>>> that cause buffer overflows on the stack are the same ones that cause
>>> buffer overflows elsewhere.
>>
>> Agreed. But 99% of systems do indeed use stacks and the "buffer
>> overflows elsewhere" are simply of no concern to the great majority of C
>> programmers.
>>
> So they don't care if they overflow a dynamic buffer?
Where did I say that?
>
>> Bottom line is this : learn how stacks work and your debugging skills
>> will be much better on those architectures with stacks (read just about
>> all platforms).
>>
> Knowing how stacks work has little bearing on detecting buffer overflow.
> Learning to spot the symptoms of overflowing an automatic variable
> does, no matter where they might be allocated.
Symptoms vary a lot. Depending on what the machine is running, the tide
being in or out. Inspecting a stack does not.
Ian Collins
>>> Agreed. But 99% of systems do indeed use stacks and the "buffer
>>> overflows elsewhere" are simply of no concern to the great majority of C
>>> programmers.
>>>
>> So they don't care if they overflow a dynamic buffer?
>
> Where did I say that?
>
You said: the "buffer overflows elsewhere" are simply of no concern to
the great majority of C programmers.
>>> Bottom line is this : learn how stacks work and your debugging skills
>>> will be much better on those architectures with stacks (read just about
>>> all platforms).
>>>
>> Knowing how stacks work has little bearing on detecting buffer overflow.
>> Learning to spot the symptoms of overflowing an automatic variable
>> does, no matter where they might be allocated.
>
> Symptoms vary a lot. Depending on what the machine is running, the tide
> being in or out. Inspecting a stack does not.
Inspecting a automatic storage does not, whether that's a stack is
irrelevant.
--
Ian Collins.
Richard
> Richard wrote:
>> Ian Collins <ian-...@hotmail.com> writes:
>>
>>> Richard wrote:
>
>>>> Agreed. But 99% of systems do indeed use stacks and the "buffer
>>>> overflows elsewhere" are simply of no concern to the great majority of C
>>>> programmers.
>>>>
>>> So they don't care if they overflow a dynamic buffer?
>>
>> Where did I say that?
>>
>
> You said: the "buffer overflows elsewhere" are simply of no concern to
> the great majority of C programmers.
Yes. You know I was referring to other stack "replacements". If not, I
apologise for not being clearer.
>
>>>> Bottom line is this : learn how stacks work and your debugging skills
>>>> will be much better on those architectures with stacks (read just about
>>>> all platforms).
>>>>
>>> Knowing how stacks work has little bearing on detecting buffer overflow.
>>> Learning to spot the symptoms of overflowing an automatic variable
>>> does, no matter where they might be allocated.
>>
>> Symptoms vary a lot. Depending on what the machine is running, the tide
>> being in or out. Inspecting a stack does not.
>
> Inspecting a automatic storage does not, whether that's a stack is
> irrelevant.
No it isn't. It's very relevant.
Ian Collins
This is starting to read like a pantomime script.
It my be relevant to you, but it never has been to me.
The End.
--
Ian Collins.
Richard
> Richard wrote:
>> Ian Collins <ian-...@hotmail.com> writes:
>>> Richard wrote:
>
>>> Inspecting a automatic storage does not, whether that's a stack is
>>> irrelevant.
>>
>> No it isn't. It's very relevant.
>
> This is starting to read like a pantomime script.
>
It is when you gratuitously snip.
> It my be relevant to you, but it never has been to me.
>
> The End.
I can only speak for myself. As for "The End", I don't really know quite
who you think you are, but I had hoped for a discussion - not the blinds
pulled down because someone disagrees with your assertions.
Richard Heathfield
> Richard wrote:
>> ric...@cogsci.ed.ac.uk (Richard Tobin) writes:
<snip>
>>> The mistakes
>>> that cause buffer overflows on the stack are the same ones that cause
>>> buffer overflows elsewhere.
>>
>> Agreed. But 99% of systems do indeed use stacks and the "buffer
>> overflows elsewhere" are simply of no concern to the great majority of C
>> programmers.
>>
> So they don't care if they overflow a dynamic buffer?
Ian, he isn't claiming that. The wording "buffer overflows elsewhere" (i.e.
not on the stack) is Richard Tobin's, and Just Richard is merely quoting
it. He's saying "look, in the real world, buffer overflows happen on the
stack, so let's deal with that".
You might not agree with his overall argument (and neither do I, as it
happens), but there's no need to put words into his mouth. He has not
claimed that people don't care if they overflow a dynamic buffer. In fact,
I think (BICBW) that at the time he said "of no concern" he wasn't
considering dynamic buffers at all, but was referring to buffer overflows
in arcane places, on systems with no stacks.
<snip>
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Ian Collins
> Ian Collins said:
>
>> Richard wrote:
>>> ric...@cogsci.ed.ac.uk (Richard Tobin) writes:
>
> <snip>
>
>>>> The mistakes
>>>> that cause buffer overflows on the stack are the same ones that cause
>>>> buffer overflows elsewhere.
>>> Agreed. But 99% of systems do indeed use stacks and the "buffer
>>> overflows elsewhere" are simply of no concern to the great majority of C
>>> programmers.
>>>
>> So they don't care if they overflow a dynamic buffer?
>
> Ian, he isn't claiming that. The wording "buffer overflows elsewhere" (i.e.
> not on the stack) is Richard Tobin's, and Just Richard is merely quoting
> it. He's saying "look, in the real world, buffer overflows happen on the
> stack, so let's deal with that".
>
> You might not agree with his overall argument (and neither do I, as it
> happens), but there's no need to put words into his mouth.
I didn't, I just misinterpreted what he wrote.
That'll teach me to get into a debate with a resident troll....
--
Ian Collins.
Richard
So you're the one who gets it wrong and I'm the troll? Laughable.
Richard Heathfield
> Ian Collins <ian-...@hotmail.com> writes:
>
>> Richard Heathfield wrote:
<snip>
>>>
>>> You might not agree with his overall argument (and neither do I, as it
>>> happens), but there's no need to put words into his mouth.
>>
>> I didn't, I just misinterpreted what he wrote.
>>
>> That'll teach me to get into a debate with a resident troll....
>
> So you're the one who gets it wrong and I'm the troll? Laughable.
Trolldom and getting-it-wrongness are not isomorphic. Trolls *deliberately*
post provocative material in the hope of drawing some kind of outraged
reaction. Kenny McCormack and Antoninus Twink are two obvious examples. If
you don't know this already, I'd be very surprised. I think you already
know, too, why Ian Collins considers you a troll. (And yes, I thought so
too, until very recently, when you had the opportunity to be very silly
about a mistake in one of my articles, but clearly made a deliberate
choice not to take that opportunity.)
Antoninus Twink
> Richard said:
>
>> Ian Collins <ian-...@hotmail.com> writes:
>>
>>> Richard Heathfield wrote:
><snip>
>>>>
>>>> You might not agree with his overall argument (and neither do I, as it
>>>> happens), but there's no need to put words into his mouth.
>>>
>>> I didn't, I just misinterpreted what he wrote.
>>>
>>> That'll teach me to get into a debate with a resident troll....
>>
>> So you're the one who gets it wrong and I'm the troll? Laughable.
>
> Trolldom and getting-it-wrongness are not isomorphic. Trolls *deliberately*
> post provocative material in the hope of drawing some kind of outraged
> reaction. Kenny McCormack and Antoninus Twink are two obvious examples. If
> you don't know this already, I'd be very surprised. I think you already
> know, too, why Ian Collins considers you a troll. (And yes, I thought so
> too, until very recently, when you had the opportunity to be very silly
> about a mistake in one of my articles, but clearly made a deliberate
> choice not to take that opportunity.)
You really are the most pompous man it's ever been my misfortune to
encounter.
Kenny McCormack
Antoninus Twink <nos...@nospam.invalid> wrote:
>On 11 Mar 2008 at 9:16, Sir Richard Heathfield, in his Majesty, graciously
>deigned to give of himself in the service of his public, and was heard
>to give his assent to the status of, as He so graciously puts it, "Just
>Plain Richard", thusly:
...
>> Trolldom and getting-it-wrongness are not isomorphic. Trolls *deliberately*
>> post provocative material in the hope of drawing some kind of outraged
>> reaction. Kenny McCormack and Antoninus Twink are two obvious examples. If
>> you don't know this already, I'd be very surprised. I think you already
>> know, too, why Ian Collins considers you a troll. (And yes, I thought so
>> too, until very recently, when you had the opportunity to be very silly
>> about a mistake in one of my articles, but clearly made a deliberate
>> choice not to take that opportunity.)
to which, the good Mr. Twink responded:
>You really are the most pompous man it's ever been my misfortune to
>encounter.
Yes, I have to agree.
Richard
> Richard said:
>
>> Ian Collins <ian-...@hotmail.com> writes:
>>
>>> Richard Heathfield wrote:
> <snip>
>>>>
>>>> You might not agree with his overall argument (and neither do I, as it
>>>> happens), but there's no need to put words into his mouth.
>>>
>>> I didn't, I just misinterpreted what he wrote.
>>>
>>> That'll teach me to get into a debate with a resident troll....
>>
>> So you're the one who gets it wrong and I'm the troll? Laughable.
>
> Trolldom and getting-it-wrongness are not isomorphic. Trolls *deliberately*
> post provocative material in the hope of drawing some kind of outraged
> reaction. Kenny McCormack and Antoninus Twink are two obvious examples. If
> you don't know this already, I'd be very surprised. I think you already
> know, too, why Ian Collins considers you a troll. (And yes, I thought so
> too, until very recently, when you had the opportunity to be very silly
> about a mistake in one of my articles, but clearly made a deliberate
> choice not to take that opportunity.)
Richard,
Let me make one thing very, very clear. I am a troll. If the definition
is someone who refuses to role over and kiss arse. There are a core
group here who delight in showing off and ridiculing other people. I
"troll" these people. I will not, and refuse to, allow them to get away
with it. I want new people to see that not everyone is unreasonable and
blinkered. This thread is a great example. How dare Collins "End Of
Story" the thread. When he was wrong IMO (and it is about opinions half
the time). And then he has the gall to somehow excuse HIS mistake and
then blame me? I was serious. I am serious. A C programmer in 99% of
implementations IS better off understanding the stack. Did he come
rolling in to "user" in order to suggest that Knuth and his reference
books are off topic? No. They provide added skills to help the
programmer. In this groups context, the C Programmer. To suggest that a
stack is "off topic" is cretinous to the extreme. I have seen people in
this group claim that a good C programmer needs no debugger. These kind
of elite, sanctimonious claims are nothing more than posing. And while
we're being reasonable, I have noticed you relax your "OT" rules
slightly - so all power to you on that one.
Richard Heathfield
> Richard Heathfield <r...@see.sig.invalid> writes:
>
>> Richard said:
>>
>>> Ian Collins <ian-...@hotmail.com> writes:
>>>
>>>> Richard Heathfield wrote:
>> <snip>
>>>>>
>>>>> You might not agree with his overall argument (and neither do I, as
>>>>> it happens), but there's no need to put words into his mouth.
>>>>
>>>> I didn't, I just misinterpreted what he wrote.
>>>>
>>>> That'll teach me to get into a debate with a resident troll....
>>>
>>> So you're the one who gets it wrong and I'm the troll? Laughable.
>>
>> Trolldom and getting-it-wrongness are not isomorphic. Trolls
>> *deliberately* post provocative material in the hope of drawing some
>> kind of outraged reaction. Kenny McCormack and Antoninus Twink are two
>> obvious examples. If you don't know this already, I'd be very surprised.
>> I think you already know, too, why Ian Collins considers you a troll.
>> (And yes, I thought so too, until very recently, when you had the
>> opportunity to be very silly about a mistake in one of my articles, but
>> clearly made a deliberate choice not to take that opportunity.)
>
> Richard,
>
> Let me make one thing very, very clear. I am a troll. If the definition
> is someone who refuses to role over and kiss arse.
That isn't my definition.
> There are a core
> group here who delight in showing off and ridiculing other people.
Yes. But we might disagree as to the membership of that core group
(although we would probably have some overlap).
> I "troll" these people.
In other words, you ridicule them. That might not be the best way to
persuade people not to use ridicule.
> I will not, and refuse to, allow them to get away with it.
You can't stop them, because it's not a moderated group.
> I want new people to see that not everyone is unreasonable and
> blinkered.
If you really want that, the way to achieve it is to lead by example, by
providing great technical help without sarcasm. Like Chris Torek does,
say.
> [...] I have noticed you relax your "OT" rules
> slightly - so all power to you on that one.
Actually, I haven't changed the rules at all. I am not in a position to do
that. I did try, by asking the group whether they were prepared to loosen
topicality a bit, and almost everyone who responded was overwhelmingly
against the idea. I'm not overly happy about that, but I'm prepared to
abide by it.
Richard
Indeed.
>
>> I "troll" these people.
>
> In other words, you ridicule them. That might not be the best way to
> persuade people not to use ridicule.
Being reasonable gets nothing back but more pompous posturing.
>
>> I will not, and refuse to, allow them to get away with it.
>
> You can't stop them, because it's not a moderated group.
No. But I can point out their anal qualities. I'm not perfect I
know. But some of these people are living in a parallel Universe.
>
>> I want new people to see that not everyone is unreasonable and
>> blinkered.
>
> If you really want that, the way to achieve it is to lead by example, by
> providing great technical help without sarcasm. Like Chris Torek does,
> say.
That's one way. I choose the other - sometimes.
>
>> [...] I have noticed you relax your "OT" rules
>> slightly - so all power to you on that one.
>
> Actually, I haven't changed the rules at all. I am not in a position
> to do
Oh well. It seemed you did. I had hoped.
> that. I did try, by asking the group whether they were prepared to loosen
> topicality a bit, and almost everyone who responded was overwhelmingly
Because the only ones who responded were the people I am referring
to. Everyone else had probably killed the thread as soon as the CLC
bible came out and a couple of you started thundering from the pulpit.
Anyway, as you so wisely pointed out, "So what. It's not a moderated
group."
> against the idea. I'm not overly happy about that, but I'm prepared to
> abide by it.
I'm not. And neither are lots of others. I will answer questions about
debuggers, and stacks and all the other things REAL breathing C
programmers use. And if that gets me back in your sinbin then so be it.
It was also wrong of you to snip and not comment on the example I gave
of typical "CLC Clique" behaviour. And if you do not see it existing
then you need a break.
This is without a doubt the most arrogant technical group I have ever
used. And I'm not alone in thinking that. A casual browse of the average
answer leaves me almost shaken
"Not on topic"
"No that wont work"
"RTFM"
"Can't speak about that here"
"Its down the road on the right"
etc etc etc ad nauseum.
At times it seems that certain posters are having a competition to see
who can post "OT" the most. It must be a close run thing between Robbie
Hatley, CBF and Default User Brian.
Chris Dollin
> I have seen people in
> this group claim that a good C programmer needs no debugger.
I've certainly claimed that I don't use one (except to get stacktraces).
I rarely use the Java debugger in Eclipse, either.
> These kind of elite, sanctimonious claims are nothing more than posing.
I think that's mere name-calling and assertion on your part.
One may infer what one chooses from the statements above (and below).
PS Redundant braces, ugh.
--
"Creation began." - James Blish, /A Clash of Cymbals/
Hewlett-Packard Limited registered office: Cain Road, Bracknell,
registered no: 690597 England Berks RG12 1HN
jacob navia
> Richard wrote:
>
>> I have seen people in
>> this group claim that a good C programmer needs no debugger.
>
> I've certainly claimed that I don't use one (except to get stacktraces).
>
Yes. Please tell me that in Technicolor.
Like this, in just black and white I do not believe you a word.
:-)
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Richard
> Richard wrote:
>
>> I have seen people in
>> this group claim that a good C programmer needs no debugger.
>
> I've certainly claimed that I don't use one (except to get
> stacktraces).
You are a wonder sir! I could never imagine not using one in a real
world project where one is extending, optimizing, fixing or refactoring
a huge legacy code base.
It is also incredibly useful, as I have stated before, to set HW break
points at known crash points, and at demonstrating program flow to new
recruits. As well as the ability to dynamically tweak parameters to force
certain situations you need to investigate.
All to their own, but I for sure would not hire or tolerate anyone who
felt that using a debugger was beneath them.
http://dirac.org/linux/gdb/01-Introduction.php
,----
| Most people use the printf() debugging method. This is called adding "trace code" to your program. Simply put, they sprinkle their code with printf() to view the value of variables at certain strategic points and also to examine the order of execution of lines of source code.
|
| There are a few reasons why this may not be the best way of doing things:
|
| 1. Sometimes you need a lot of printf()'s, and it can get tedious putting them in and taking them out. Inserting and deleting superfluous code all the time is really distracting. It draws attention away from what you're doing. It's like trying to implement a linked list while someone is talking to you about last night's Futurama episode.
| 2. A symbolic debugger can do an awful lot that printf() can't. You can do just about anything you can think of, including changing the value of variables at run-time, halt the program temporarily, list source code, printo the datatype of a variable or struct that you don't recognize, jump to an arbitrary line of code, and much, much more.
| 3. You can use a symbolic debugger on a running process; you don't even have to kill the process! Try that with printf()!
| 4. You can use a symbolic debugger on a process that has already crashed and died without having to re-run the program. You'll see the state the program was in at the time of death and can inspect all the variables.
| 5. A knowledge of GDB will increase your knowledge of programs, processes, memory and your language of choice.
`----
>
> I rarely use the Java debugger in Eclipse, either.
>
>> These kind of elite, sanctimonious claims are nothing more than posing.
>
> I think that's mere name-calling and assertion on your part.
I would like to reword. I would like to insert the word "generally" in there.
>
> One may infer what one chooses from the statements above (and below).
>
> PS Redundant braces, ugh.
*shrug*
Statistics and experience of projects has led me to believe that braces
in at the start leads to less "braces missing" type errors ... not
surprisingly.
Richard
> Chris Dollin wrote:
>> Richard wrote:
>>
>>> I have seen people in
>>> this group claim that a good C programmer needs no debugger.
>>
>> I've certainly claimed that I don't use one (except to get stacktraces).
>>
>
> Yes. Please tell me that in Technicolor.
>
> Like this, in just black and white I do not believe you a word.
>
> :-)
I seem to recall that CBF also claims he never needed one.
Astonishing.
Either planet sized brains or have never, ever worked on any code base
contributed to by anyone else. Or never had to find an error in a system
which occurs 5 hours into it running etc etc. Must be very limited
experience.
Morris Dovey
>
> Richard said:
> > [...] I have noticed you relax your "OT" rules
> > slightly - so all power to you on that one.
>
> Actually, I haven't changed the rules at all. I am not in a position to do
> that. I did try, by asking the group whether they were prepared to loosen
> topicality a bit, and almost everyone who responded was overwhelmingly
> against the idea. I'm not overly happy about that, but I'm prepared to
> abide by it.
Historically, the group has exhibited a tendancy to relax the
rules for those who've exhibited competency and who've
participated constructively over a period of time.
In spite of all the visible evidence that subscribers here are
too nerdy/geekish to care about anything other than programming,
it may help you to understand that over time the regulars have
gotten to know and value each other as human beings, and that
these people care about each other to a degree that you would
probably find astonishing.
I've concluded from some of your remarks that you perceive some
kind of power structure here - and I'd like you to know that by
looking for that, you've misdirected your attentions and led
yourself to some faulty conclusions.
It's worth noting that Heathfield has no more power here than you
or I or anyone else - and that what he does have is the earned
respect of knowledgable peers. Having that respect means that his
technical writings will be taken seriously. It does not mean that
the group automatically accepts what he says as gospel, but that
the group has learned that he's worth listening to. FWIW, my
personal take is that he also has a delightful sense of humor
with a sometimes sneaky subtlety. He's a straight-shooter and
he's generous enough to be willing to give better than he gets.
Like most Brits he sneaks extra letters into his words.
It's not a clique - it's a close community of individuals seeking
to serve the wider and more general programming community.
There's not a regular here who doesn't understand stacks - and I
doubt there're any who don't have a good grasp of stack frames -
but traffic levels here just don't allow discussion of
architecture to become part of the norm. It's not a matter of
excluding machine architecture (there really is a lot of interest
in this area) but rather of spreading the newsgroup so thinly
that it becomes worthless. If you have difficulty seeing how this
might be so, then for a period of two weeks, make an honest
effort to respond correctly (in terms of the latest C standards
document) to every new thread, and also keep an eye on every
other response given so as to ensure that posters receive
universally accurate responses. Warning: it isn't as easy as it
might look.
It's not difficult to understand that your own knowledge extends
beyond what's covered by the standard - and it'd probably help
for you to recognize that's so for every regular here. It's (in
part) the diversity of "outside knowledge" that allows the
newsgroup to be however useful it is.
--
Morris Dovey
DeSoto Solar
DeSoto, Iowa USA
http://www.iedu.com/DeSoto/
Antoninus Twink
> It's not a clique - it's a close community of individuals
It's not a dog - it's a small hairy animal that wags its tail and barks.
David Resnick
> Chris Dollin <chris.dol...@hp.com> writes:
> > Richard wrote:
>
> >> I have seen people in
> >> this group claim that a good C programmer needs no debugger.
>
> > I've certainly claimed that I don't use one (except to get
> > stacktraces).
>
> You are a wonder sir! I could never imagine not using one in a real
> world project where one is extending, optimizing, fixing or refactoring
> a huge legacy code base.
>
> It is also incredibly useful, as I have stated before, to set HW break
> points at known crash points, and at demonstrating program flow to new
> recruits. As well as the ability to dynamically tweak parameters to force
> certain situations you need to investigate.
>
> All to their own, but I for sure would not hire or tolerate anyone who
> felt that using a debugger was beneath them.
I don't personally think the debugger is very useful. I use it for
analyzing core files. Haven't used it for much else in 8 years of a
mixture of C and C++ programming (yes, I know many here have longer
experience in programming). I believe that use of a debugger is a
fine choice, just not for me except in certain limited circumstances.
Mind you, many of the harder problems to debug in the large (and of
course multithreaded) group of apps I work on happen only under heavy
load where breakpoints/etc are not really useful. Would you hire the
"fools" who said this:
"As a personal choice, we tend not to use debuggers beyond getting a
stack trace or the value of a variable or two. One reason is that it
is easy to get lost in details of complex data structures and control
flow..." Kernighan and Pike, The Practice of Programming, p119.
They say later in the paragraph that a good debugger is a powerful
tool in some cases. But you are arguing far too strongly that it
basically essential for development of complex systems. Different
people have different development styles. You think debuggers and
stepping through code are an integral part of development/testing/
etc. I find using logging messages together with tools like Valgrind
and Rational Purify/Quantify much more useful. And I'd say whatever
works for each developer to get the job done is fine, no reason for
all the ire. Some people even manage to develop code without using
emacs, which I simply can't understand...
-David
Morris Dovey
> Either planet sized brains or have never, ever worked on any code base
> contributed to by anyone else. Or never had to find an error in a system
> which occurs 5 hours into it running etc etc. Must be very limited
> experience.
My mileage varies, but I haven't found a debugger that does much
for me in debugging thread interactions in real time
environments, but I'm willing to concede that I might find 'em
more useful if I had more experience.
Richard Heathfield
> Richard Heathfield <r...@see.sig.invalid> writes:
>
>> Richard said:
>>
<snip>
>>
>>> I "troll" these people.
>>
>> In other words, you ridicule them. That might not be the best way to
>> persuade people not to use ridicule.
>
> Being reasonable gets nothing back but more pompous posturing.
Being *un*reasonable is surely not the best way to go.
>>> I will not, and refuse to, allow them to get away with it.
>>
>> You can't stop them, because it's not a moderated group.
>
> No. But I can point out their anal qualities. I'm not perfect I
> know. But some of these people are living in a parallel Universe.
You can't stop that. Neither can I. Adding to their number doesn't help
anything.
>>> I want new people to see that not everyone is unreasonable and
>>> blinkered.
>>
>> If you really want that, the way to achieve it is to lead by example, by
>> providing great technical help without sarcasm. Like Chris Torek does,
>> say.
>
> That's one way. I choose the other - sometimes.
That is a shame.
>>> [...] I have noticed you relax your "OT" rules
>>> slightly - so all power to you on that one.
>>
>> Actually, I haven't changed the rules at all. I am not in a position
>> to do
>
> Oh well. It seemed you did. I had hoped.
I bend them occasionally.
>> that. I did try, by asking the group whether they were prepared to
>> loosen topicality a bit, and almost everyone who responded was
>> overwhelmingly
>
> Because the only ones who responded were the people I am referring
> to.
I don't think so. For example, *you* responded (with a view on topicality
that isn't all that far from my own). Likewise Chris Hills. Ian Collins
and Jack Klein put forward /more/ liberal views than either yours or mine.
> Everyone else had probably killed the thread as soon as the CLC
> bible came out and a couple of you started thundering from the pulpit.
Well, if people aren't willing to make known their views on topicality, the
group can't realistically take their views into account.
> Anyway, as you so wisely pointed out, "So what. It's not a moderated
> group."
>
>> against the idea. I'm not overly happy about that, but I'm prepared to
>> abide by it.
>
> I'm not. And neither are lots of others. I will answer questions about
> debuggers, and stacks and all the other things REAL breathing C
> programmers use.
That's your choice, obviously. The trouble with that route (and it's a
route with which I have a certain amount of sympathy) is that there's no
clear place to draw the line. After all, REAL breathing C programmers use
cars to get to work, but presumably you don't think cars or coffee should
be topical here. Usenet is partitioned into topic groups for a reason.
> And if that gets me back in your sinbin then so be it.
I don't killfile people if I think they're behaving reasonably. I don't
agree entirely with your topicality stance, but I have never yet killfiled
a clc regular for posting off-topic articles.
> It was also wrong of you to snip and not comment on the example I gave
> of typical "CLC Clique" behaviour. And if you do not see it existing
> then you need a break.
Actually, it wasn't wrong of me to do that. Usenet is not only a strange
place, but also a vast one, and my time is limited. I don't have time to
talk about all the things I'd /like/ to discuss, let alone the things that
bore me to sleep, and this "CLC Clique" subject is in the latter category.
A clique is exclusive by definition. Anyone can post here, so the group is
not a clique. The only discriminatory factor that I see working here is
that of merit - i.e. knowledge of and ability to discuss the C programming
language. If you wish to describe the set of people who have that
knowledge and that ability as a "clique", that's up to you - but calling a
horse a zebra doesn't add a single stripe to its coat.
> This is without a doubt the most arrogant technical group I have ever
> used.
Okay, so change it by example.
> And I'm not alone in thinking that. A casual browse of the average
> answer leaves me almost shaken
So change the average answer, by posting better-than-average answers.
>
> "Not on topic"
> "No that wont work"
> "RTFM"
> "Can't speak about that here"
> "Its down the road on the right"
>
> etc etc etc ad nauseum.
To some extent it's inevitable. Usenet is topic-based, and there really are
places where people can get much better help on <foo> than can be provided
here, where <foo> is some subject only tangentially related to C
programming. Nevertheless, it is a shame, especially when people /say/
something is off-topic when in fact it isn't! That happens more often than
it should.
> At times it seems that certain posters are having a competition to see
> who can post "OT" the most.
Well, you *can't* change that by ridiculing them. Many of them don't even
see your replies, because you're in their killfiles. Nor are you likely to
be able to change it by persuading them. If you don't want to read what
they write, killfile them. If you'd rather they didn't write it at all,
you're out of luck. Neither you nor I get to decide what other people
write.
> It must be a close run thing between Robbie
> Hatley, CBF and Default User Brian.
<shrug> If you want to increase the S/N ratio in comp.lang.c, you won't
ever do that by adding to the noise. Add to the signal instead.
Kenny McCormack
Richard <de...@gmail.com> wrote:
...
>At times it seems that certain posters are having a competition to see
>who can post "OT" the most. It must be a close run thing between Robbie
>Hatley, CBF and Default User Brian.
What about me? Don't I get credit for being up there in terms of doing
the "OT Dance"?
Kenny McCormack
Richard <de...@gmail.com> wrote:
...
>Let me make one thing very, very clear. I am a troll. If the definition
>is someone who refuses to role over and kiss arse. There are a core
Oh, Just Plain Richard, now you've done it. You've self-identified as a
troll. There's no going back. I did this myself several years back
and, among other things, absolutely made Keith Thompson's day. He
celebrates in bringing up the memory every chance he gets.
To continue the religion analogy: Admitting to being a troll in this NG
is like admitting to being a non-Christian in medieval Europe. That's
it; that's the end of the story. No further proof of anything is
needed.
Quoting a scene from JC Superstar:
There you have it, gentlemen. What more evidence do you need?
Keithy, thank you for the victim. Stay awhile and you'll see it
bleed.
>group here who delight in showing off and ridiculing other people. I
>"troll" these people.
And we love you for it.
Richard
> On Mar 11, 11:43 am, Richard <de...@gmail.com> wrote:
>> Chris Dollin <chris.dol...@hp.com> writes:
>> > Richard wrote:
>>
>> >> I have seen people in
>> >> this group claim that a good C programmer needs no debugger.
>>
>> > I've certainly claimed that I don't use one (except to get
>> > stacktraces).
>>
>> You are a wonder sir! I could never imagine not using one in a real
>> world project where one is extending, optimizing, fixing or refactoring
>> a huge legacy code base.
>>
>> It is also incredibly useful, as I have stated before, to set HW break
>> points at known crash points, and at demonstrating program flow to new
>> recruits. As well as the ability to dynamically tweak parameters to force
>> certain situations you need to investigate.
>>
>> All to their own, but I for sure would not hire or tolerate anyone who
>> felt that using a debugger was beneath them.
>
> I don't personally think the debugger is very useful. I use it for
If you don't think the ability to set HW break points/watch conditions on
complex matches in order to stop the process possibly hours into a run
is not useful then I really do not know what to say. if you dont think
the ability to dynamically change run time parameters to force certain
trigger parameters is useful then I'm astonished.
The only thing I can guess is that you work on very small, well
structured code bases for which you are almost solely responsible for.
And fair enough.
But some people here recommend against using them. There is a difference.
> analyzing core files. Haven't used it for much else in 8 years of a
> mixture of C and C++ programming (yes, I know many here have longer
> experience in programming). I believe that use of a debugger is a
> fine choice, just not for me except in certain limited circumstances.
Fair enough. Possibly. But I suspect your productivity would be much
better if you used one regularly. maybe. Maybe not. We'll not agree I'm
sure.
> Mind you, many of the harder problems to debug in the large (and of
> course multithreaded) group of apps I work on happen only under heavy
> load where breakpoints/etc are not really useful. Would you hire the
> "fools" who said this:
No. I would not.
>
> "As a personal choice, we tend not to use debuggers beyond getting a
> stack trace or the value of a variable or two. One reason is that it
"or the value of a variable or two". This is so open to interpretation
it is unbelievable. And as for the stack trace! What? There is NO
stack. Remember :-;
> is easy to get lost in details of complex data structures and control
> flow..." Kernighan and Pike, The Practice of Programming, p119.
I disagree with them. Of course I respect them. I wonder how many
existing code bases they maintained and extended? I wonder how good
debuggers were back then? TBH, I'm sick of seeing that quote trotted
out. I know what a debugger can do. I use it to do it. There is NO WAY I
could find those bugs from a print out of a 2.5 Million line code
base. I suspect that the debuggers available then were a fraction of
what is available now.
I would be interested to hear which bits of the following article you
disagree with:
http://dirac.org/linux/gdb/01-Introduction.php
Or is that guy wrong? Is Stallman wrong?
>
> They say later in the paragraph that a good debugger is a powerful
> tool in some cases. But you are arguing far too strongly that it
> basically essential for development of complex systems. Different
It is IMO. Note the IMO. Maybe we have worked on different things. I can
only have my reasoned opinion. Developing code without using a good
debugger is, IMO, madness.
> people have different development styles. You think debuggers and
> stepping through code are an integral part of development/testing/
I do. And more importantly familiarisation.
> etc. I find using logging messages together with tools like Valgrind
> and Rational Purify/Quantify much more useful. And I'd say whatever
Valgrind is essential too.
> works for each developer to get the job done is fine, no reason for
> all the ire. Some people even manage to develop code without using
> emacs, which I simply can't understand...
Emacs is falling behind the curve unfortunately. I use it too. I would
be interested to hear about your setup.
I gave up using ecb as it added no value. Semantic doesn't seem to do
much. Cscope and etags are ok. I never got code completion working
properly.
Kenny McCormack
Part of the definition of a "clique" is that everyone denies its
existence, but everyone knows it exists.
Richard
> Richard wrote:
>
>> Either planet sized brains or have never, ever worked on any code base
>> contributed to by anyone else. Or never had to find an error in a system
>> which occurs 5 hours into it running etc etc. Must be very limited
>> experience.
>
> My mileage varies, but I haven't found a debugger that does much
> for me in debugging thread interactions in real time
> environments, but I'm willing to concede that I might find 'em
> more useful if I had more experience.
With every release gdb gets better in that respect. Having said that its
not something I know too much about (embedded systems that is).
clc is the only place I have seen so much resistance to debugging. Some
mean it. Most are simply posing for the camera I think.
Richard
> Richard said:
>
>> Richard Heathfield <r...@see.sig.invalid> writes:
>>
>>> Richard said:
>>>
> <snip>
>>>
>>>> I "troll" these people.
>>>
>>> In other words, you ridicule them. That might not be the best way to
>>> persuade people not to use ridicule.
>>
>> Being reasonable gets nothing back but more pompous posturing.
>
> Being *un*reasonable is surely not the best way to go.
Who said anything about being unreasonable? I am always reasonable. Or
reasonably so ...
It is not unreasonable to refer to CBF as a pompous ass with too much of
an opinion of his own abilities when all he does is get things wrong and
insult people.
Kenny McCormack
Richard <de...@gmail.com> wrote:
...
>With every release gdb gets better in that respect. Having said that its
>not something I know too much about (embedded systems that is).
>
>clc is the only place I have seen so much resistance to debugging. Some
>mean it. Most are simply posing for the camera I think.
It *is* just posturing. The regs (and reg wannabees like David) want to
feel like mathematicians - who are able to prove their programs correct,
w/o any testing. As we all know, this is a very appealing thought, but
one without much real world traction.
Richard
> Richard Heathfield wrote:
>>
>> Richard said:
>
>> > [...] I have noticed you relax your "OT" rules
>> > slightly - so all power to you on that one.
>>
>> Actually, I haven't changed the rules at all. I am not in a position to do
>> that. I did try, by asking the group whether they were prepared to loosen
>> topicality a bit, and almost everyone who responded was overwhelmingly
>> against the idea. I'm not overly happy about that, but I'm prepared to
>> abide by it.
>
> Historically, the group has exhibited a tendancy to relax the
> rules for those who've exhibited competency and who've
> participated constructively over a period of time.
Rubbish. It depends on whose side they see you on. The "standards nazis"
or the "lets be open man hippies".
>
> In spite of all the visible evidence that subscribers here are
> too nerdy/geekish to care about anything other than programming,
> it may help you to understand that over time the regulars have
> gotten to know and value each other as human beings, and that
No they haven't. They got to know each other as CLC members.
> these people care about each other to a degree that you would
> probably find astonishing.
I have been in and out of this group for years. Some times extended
absences and so I can see the changes more clearly.
>
> I've concluded from some of your remarks that you perceive some
> kind of power structure here - and I'd like you to know that by
There is a "perceived one".
> looking for that, you've misdirected your attentions and led
> yourself to some faulty conclusions.
Wrong. My conclusions are simple : there are too many smart alecs who
take too much enjoyment in being pedantic arses. There is nothing
incorrect about that. Read the posts if you dont believe me. And if you
do not see it then you've been here too long too.
>
> It's worth noting that Heathfield has no more power here than you
> or I or anyone else - and that what he does have is the earned
Its not worth noting at all. Of course he has no more power. Any
"perceived power" is purely based on quality of posts OR ones strict
adherence to the clique mantra. Dont believe me? Look at how a few
lickspittles trot out the old "I can assure you he knows more about this
than you" garbage.
I'm sorry Morris, but your little bit of prose almost sums up whats
wrong with this group. You do indeed go on about "earning ones
stripes". Fine. And not a bad thing. But not when it starts to spiral
into a hotbed of name calling and petty spitefulness as I have seen
against Jacob and various others.