subroutine stack and C machine model
Frank
weekend. Does the abstract machine that is described in the standard
have a subroutine stack?
I've heard before that one can imagine things as a stack, and that
wouldn't be wrong, but then again it wouldn't be right. The comment
I'm looking for is not what the standard prohibits in terms of
allegories.
Instead I'm trying to think of what might be useful, given that there
is an execution register, and that it amounts to a stack. Does C have
a function that changes what happens in the execution register?
Kenny McCormack
Frank <mer...@lomas-assault.net> wrote:
>I'm looking and talking about a lot of C that is new to me this
>weekend. Does the abstract machine that is described in the standard
>have a subroutine stack?
>
>I've heard before that one can imagine things as a stack, and that
>wouldn't be wrong, but then again it wouldn't be right. The comment
>I'm looking for is not what the standard prohibits in terms of
>allegories.
If you use the 's-word' in this newsgroup, you will be shunned.
Further, the hyper-literal minded, autistics/Asbergers patient types
here, don't do well with allegories. They are, as I'm sure Kiki will
tell you by and by, best avoided.
Richard Heathfield
<8ab64971-735c-48af...@v15g2000prn.googlegroups.com>,
Frank wrote:
> I'm looking and talking about a lot of C that is new to me this
> weekend. Does the abstract machine that is described in the
> standard have a subroutine stack?
The Standard does not say so. Conceptually, it can help to think of
nested calls in stack terms: if main calls foo, and foo calls bar,
and bar calls baz, then it can be useful to think of a stack with
main at the bottom and bar at the top (with "bottom" and "top" being
logical terms, not necessarily addressical(tm) terms).
> I've heard before that one can imagine things as a stack, and that
> wouldn't be wrong, but then again it wouldn't be right.
That's about it, yes. It's a picture that the Standard doesn't quite
paint, but it can be a useful picture, as long as you don't mistake
it for a photograph. That is, in terms of portable C programming it
is not a good idea to assume that your picture is a 100% faithful
representation of reality. For example, if you decide that you will
use the stacklike nature of your function call history to work out
where in memory the return address is stored and then overwrite that
address with the address of some other routine, that may well work -
but you would place your program firmly in the land of Undefined
Behaviour.
> The comment
> I'm looking for is not what the standard prohibits in terms of
> allegories.
I don't think the C Standard either allows or prohibits any
allegories. It is strangely silent on the matter.
> Instead I'm trying to think of what might be useful, given that
> there is an execution register, and that it amounts to a stack.
What might be useful depends on what you need to do. If you need to
write portable C code, don't assume a stack. If you need to write
non-portable C code (that is, if your need for a non-portable feature
outweighs your need for portability), check your implementation's
documentation.
> Does C have a function that changes what happens in the execution
> register?
It's not quite clear what you mean by "execution register". It may be
that your question is one to which "setjmp/longjmp" might be a
sensible (or at least not totally nonsensical) answer. Having said
that, those are not two of my favourite functions.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within
Seebs
> I'm looking and talking about a lot of C that is new to me this
> weekend. Does the abstract machine that is described in the standard
> have a subroutine stack?
I'm not quite sure, but I think the answer is no. Unless I don't
understand what you mean by a subroutine stack, in which case the
answer is probably no.
> Instead I'm trying to think of what might be useful, given that there
> is an execution register, and that it amounts to a stack. Does C have
> a function that changes what happens in the execution register?
I don't think I understand. If you're wondering about breaking the
calling sequence, consider setjmp()/longjmp().
-s
--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
Seebs
> Further, the hyper-literal minded, autistics/Asbergers patient types
> here, don't do well with allegories.
I am assured by people who apparently give a flying fuck that people
treating patients with autism prefer the phrase "people with autism" to
"autistics". The name of the syndrome, BTW, is "Asperger's".
However, it is not necessarily the case that people with various
autism-spectrum traits don't do well with allegories; if anything, many
of them do exceptionally well with allegories, because they are conscious
that the allegory is a tool for thinking about something, not the reality
of the thing described.
>They are, as I'm sure Kiki will
> tell you by and by, best avoided.
Doubtless. Certainly, if I were jealous of people who were much better
at something than I, it would make sense for me to tell other people to
avoid them.
Stephen Sprunk
> I'm looking and talking about a lot of C that is new to me this
> weekend. Does the abstract machine that is described in the standard
> have a subroutine stack?
>
> I've heard before that one can imagine things as a stack, and that
> wouldn't be wrong, but then again it wouldn't be right. The comment
> I'm looking for is not what the standard prohibits in terms of
> allegories.
It may help you to think of nested function calls in terms of an
abstract stack, and many/most implementations actually do use a stack
because that's a logical way to do things*. The Standard does not
require one to exist, though, and even if your implementation does have
one, you'd best not go looking for "the stack" or try to examine it
unless you want your code to be utterly non-portable.
> Instead I'm trying to think of what might be useful, given that there
> is an execution register, and that it amounts to a stack. Does C have
> a function that changes what happens in the execution register?
I have no idea what you mean by "execution register".
S
--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
jacob navia
> I'm looking and talking about a lot of C that is new to me this
> weekend. Does the abstract machine that is described in the standard
> have a subroutine stack?
>
> I've heard before that one can imagine things as a stack, and that
> wouldn't be wrong, but then again it wouldn't be right.
C assumes a stack, and if the machine has no
stack register it must be implemented in software.
> The comment
> I'm looking for is not what the standard prohibits in terms of
> allegories.
>
The standard doesn't say it explicitely but the structure of
the language assumes a stack.
If main alls initialize, and initialize calls malloc we have
a stack of
main
initialize
malloc
and when malloc finishes, the stack is popped and we are in
initialize. When initialize is finished we pop the stack
and we get into main again.
> Instead I'm trying to think of what might be useful, given that there
> is an execution register, and that it amounts to a stack. Does C have
> a function that changes what happens in the execution register?
It is unclear what you meanby "execution register".
Nick Keighley
> On 2009-10-12, Kenny McCormack <gaze...@shell.xmission.com> wrote:
>
> > Further, the hyper-literal minded, autistics/Asbergers patient types
> > here, don't do well with allegories.
>
> I am assured by people who apparently give a flying fuck that people
> treating patients with autism prefer the phrase "people with autism" to
> "autistics". The name of the syndrome, BTW, is "Asperger's".
>
> However, it is not necessarily the case that people with various
> autism-spectrum traits don't do well with allegories; if anything, many
> of them do exceptionally well with allegories, because they are conscious
> that the allegory is a tool for thinking about something, not the reality
> of the thing described.
interesting. I come across a lot of people that don't seem to get
allegories and metaphors. They confuse the metaphor with the thing.
What I call abstraction-blindness.
"you can think of electricity as a fluid..."
"is it a fluid?"
"well it can be a usful model, voltage is like..."
"but, is it *really" a fluid?"
"depends what you mean by \"is\""
Is there an an-autistic syndrome?
Nick Keighley
> In
> <8ab64971-735c-48af-8642-e79b03faa...@v15g2000prn.googlegroups.com>,
> > The comment
> > I'm looking for is not what the standard prohibits in terms of
> > allegories.
>
> I don't think the C Standard either allows or prohibits any
> allegories. It is strangely silent on the matter.
"O, there's nothing to be hoped for from her! she's as headstrong as
an allegory on the banks of the Nile"
Keith Thompson
> Frank a écrit :
>> I'm looking and talking about a lot of C that is new to me this
>> weekend. Does the abstract machine that is described in the standard
>> have a subroutine stack?
>>
> Yes
>
>> I've heard before that one can imagine things as a stack, and that
>> wouldn't be wrong, but then again it wouldn't be right.
>
> C assumes a stack, and if the machine has no
> stack register it must be implemented in software.
To be clear, there must be some stack-like (last-in first-out)
data structure to implement the set of information necessary to keep
track of the currently active set of function calls. This stack can
be implemented in any of a number of ways. A contiguous hardware
stack with a dedicated register pointing to the top is the most
common implementation.
jacob, I presume that's what you meant. I'm not sure what you
mean by "stack register". Obviously there must be some mechanism
to keep track of the top of the stack, and a dedicated hardware
register is a common choice, but it's not required or implied that
it should be a register.
The problem, as we've discussed at great length many times, is that
the phrase "the stack" is often used to refer to a particular kind
of stack implementation, one that's very common but not universal.
It's interesting to note that the C Standard fully describes the
semantics of the language without using the word "stack".
The distinction between a contiguous hardware stack and an abstract
stack (i.e., anything that implements a last-in first-out data
structure) is critical here.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Chris Dollin
> To be clear, there must be some stack-like (last-in first-out)
> data structure to implement the set of information necessary to keep
> track of the currently active set of function calls.
Nitpick: only if there's some recursion. Otherwise each function can
have its own static area for storing locals & return addresses.
If there's no recursion and no function-pointer variables, the compiler
could "just" inline everything!
--
"The view from where I stand begins to change." - The Reasoning, /Awakening/
Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England
BGB / cr88192
"Frank" <mer...@lomas-assault.net> wrote in message
news:8ab64971-735c-48af...@v15g2000prn.googlegroups.com...
> I'm looking and talking about a lot of C that is new to me this
> weekend. Does the abstract machine that is described in the standard
> have a subroutine stack?
>
in an abstract sense, one may exist (defined in terms of the function
calling sequence).
but, it need not be a HW stack...
> I've heard before that one can imagine things as a stack, and that
> wouldn't be wrong, but then again it wouldn't be right. The comment
> I'm looking for is not what the standard prohibits in terms of
> allegories.
>
C doesn't prohibit a graph representation either, only that I don't know of
any real implementations that do it this way.
for example, if opposed to having a linear stack (FIFO WRT function calls),
one instead has a linked-list of "call frames", where calling each function
creates a new frame and begins execution within this frame, and upon
completion returns to the parent frame.
in this case, for simple code it just happens to resemble the good old
familiar stack model.
now, where this would start to show itself, would be if one were to add a
feature, lets call it "call/cc", which would capture an object known as a
'continuation' and allow an inner function to 'call' back into the original
frame which executed the call/cc, and maybe from there actually call back
into the frame which called outwards, ...
(I decided against providing an example of this...).
but, at this point, even the conceptual model of the stack could shatter,
and the standard need not actually prohibit this sort of implementation.
(I may note here that newer versions of the JVM are actually implementing
this feature, granted, Java is not C...).
> Instead I'm trying to think of what might be useful, given that there
> is an execution register, and that it amounts to a stack. Does C have
> a function that changes what happens in the execution register?
"execution register" is not a standard term, one is stepping on thin ice
here...
but, as others have noted, there is setjmp/longjmp, which allow non-local
control-flow transfers (in a form that some other languages would term "exit
only continuations").
then the big "can of worms" would be if longjmp were allowed to actually
jump back into a place it previously jumped out of.
Lew Pitcher
(cr8...@hotmail.com) wrote:
>
> "Frank" <mer...@lomas-assault.net> wrote in message
> news:8ab64971-735c-48af...@v15g2000prn.googlegroups.com...
>> I'm looking and talking about a lot of C that is new to me this
>> weekend. Does the abstract machine that is described in the standard
>> have a subroutine stack?
>>
>
> in an abstract sense, one may exist (defined in terms of the function
> calling sequence).
> but, it need not be a HW stack...
>
>
>> I've heard before that one can imagine things as a stack, and that
>> wouldn't be wrong, but then again it wouldn't be right. The comment
>> I'm looking for is not what the standard prohibits in terms of
>> allegories.
>>
>
> C doesn't prohibit a graph representation either, only that I don't know
> of any real implementations that do it this way.
>
> for example, if opposed to having a linear stack (FIFO WRT function
> calls), one instead has a linked-list of "call frames", where calling each
> function creates a new frame and begins execution within this frame, and
> upon completion returns to the parent frame.
This is, in essence, how the CODE/370 C compilers (on IBM's MVS and Z-OS
mainframe operating systems) build their code.
> in this case, for simple code it just happens to resemble the good old
> familiar stack model.
>
>
> now, where this would start to show itself, would be if one were to add a
> feature, lets call it "call/cc", which would capture an object known as a
> 'continuation' and allow an inner function to 'call' back into the
> original frame which executed the call/cc, and maybe from there actually
> call back into the frame which called outwards, ...
I don't understand your idea here. Are you exploring the sort of thing a
co-routine might do, or are you exploring the sort of thing recursion might
do?
In the case of recursion, the CODE/370 (and followon) compiler(s) would
allocate a new "call frame", and link it back to the old one. The new "call
frame" would handle the current (recursed) function invocation's local
memory requirements until that function terminates, then would be unlinked
and discarded, with the previous "call frame" being returned to prominence.
You get the effects (and limitations) of a hardware stack without actually
having a CPU-enforced hardware stack.
I can't say /how/ co-routines would work. I don't know of any example that
shows the switching between two functions without a function call (and thus
an implicit allocation of a new "call frame").
> (I decided against providing an example of this...).
>
> but, at this point, even the conceptual model of the stack could shatter,
> and the standard need not actually prohibit this sort of implementation.
>
> (I may note here that newer versions of the JVM are actually implementing
> this feature, granted, Java is not C...).
[snip]
--
Lew Pitcher
Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/ | GPG public key available by request
---------- Slackware - Because I know what I'm doing. ------
Keith Thompson
> Keith Thompson wrote:
>> To be clear, there must be some stack-like (last-in first-out)
>> data structure to implement the set of information necessary to keep
>> track of the currently active set of function calls.
>
> Nitpick: only if there's some recursion. Otherwise each function can
> have its own static area for storing locals & return addresses.
>
> If there's no recursion and no function-pointer variables, the compiler
> could "just" inline everything!
Meta-nitpick: In the abstract machine, the set of currently active
function calls does behave in a last-in first-out manner, even if
the implementation pre-allocates activation records and/or doesn't
take any action to deallocate them when they're no longer active.
An implementation in which a non-recursive program has a statically
allocated activation record for each function is just another example
where a "stack" (in the abstract sense) is implemented by a method
other than a classic contiguous hardware stack.
BGB / cr88192
"Lew Pitcher" <lpit...@teksavvy.com> wrote in message
news:3fa4f$4ad34aac$cef8a40f$26...@TEKSAVVY.COM...
> On October 12, 2009 11:17, in comp.lang.c, BGB / cr88192
> (cr8...@hotmail.com) wrote:
>
>>
>> "Frank" <mer...@lomas-assault.net> wrote in message
>> news:8ab64971-735c-48af...@v15g2000prn.googlegroups.com...
>>> I'm looking and talking about a lot of C that is new to me this
>>> weekend. Does the abstract machine that is described in the standard
>>> have a subroutine stack?
>>>
>>
>> in an abstract sense, one may exist (defined in terms of the function
>> calling sequence).
>> but, it need not be a HW stack...
>>
>>
>>> I've heard before that one can imagine things as a stack, and that
>>> wouldn't be wrong, but then again it wouldn't be right. The comment
>>> I'm looking for is not what the standard prohibits in terms of
>>> allegories.
>>>
>>
>> C doesn't prohibit a graph representation either, only that I don't know
>> of any real implementations that do it this way.
>>
>> for example, if opposed to having a linear stack (FIFO WRT function
>> calls), one instead has a linked-list of "call frames", where calling
>> each
>> function creates a new frame and begins execution within this frame, and
>> upon completion returns to the parent frame.
>
> This is, in essence, how the CODE/370 C compilers (on IBM's MVS and Z-OS
> mainframe operating systems) build their code.
>
ok.
>> in this case, for simple code it just happens to resemble the good old
>> familiar stack model.
>>
>>
>> now, where this would start to show itself, would be if one were to add a
>> feature, lets call it "call/cc", which would capture an object known as a
>> 'continuation' and allow an inner function to 'call' back into the
>> original frame which executed the call/cc, and maybe from there actually
>> call back into the frame which called outwards, ...
>
> I don't understand your idea here. Are you exploring the sort of thing a
> co-routine might do, or are you exploring the sort of thing recursion
> might
> do?
>
> In the case of recursion, the CODE/370 (and followon) compiler(s) would
> allocate a new "call frame", and link it back to the old one. The new
> "call
> frame" would handle the current (recursed) function invocation's local
> memory requirements until that function terminates, then would be unlinked
> and discarded, with the previous "call frame" being returned to
> prominence.
> You get the effects (and limitations) of a hardware stack without actually
> having a CPU-enforced hardware stack.
>
> I can't say /how/ co-routines would work. I don't know of any example that
> shows the switching between two functions without a function call (and
> thus
> an implicit allocation of a new "call frame").
>
I was talking about 'continuations'.
http://en.wikipedia.org/wiki/Continuation
these don't traditionally exist in C-family languages, but are common in
many functional languages, including, for example, Scheme, ...
the main difficulty with them is that it is difficult to add them without
introducing a lot of "issues" (such as needing to use a heap-like structure
for call frames, deal with the issue that call frames may continue to exist
after a given function returns, ...).
none the less, I was mostly pointing out that they "could" be added to C,
which would more or less break a stack-centric mindset of the call/return
process (essentially replacing it with a graph structure).
or such...
Herbert Rosenau
wrote:
> I'm looking and talking about a lot of C that is new to me this
> weekend. Does the abstract machine that is described in the standard
> have a subroutine stack?
As the standard says nothing about stack you casn savely assume that
there is not known by C what a stack is, how it is used (when there is
one). The same is for heap.
> I've heard before that one can imagine things as a stack, and that
> wouldn't be wrong, but then again it wouldn't be right. The comment
> I'm looking for is not what the standard prohibits in terms of
> allegories.
You can savely assume that the abstract mashine uses something that
makes recursive calls possible but it lefts it open to the
implementation how that will go on.
> Instead I'm trying to think of what might be useful, given that there
> is an execution register, and that it amounts to a stack. Does C have
> a function that changes what happens in the execution register?
The abstract mashine knows nothing about registers, stack(s), heap(s).
So it is left to the implkementation to use registers, stack(s),
heap(s) in a manner the real environment the implementation runs under
does (not) implement them.
For portability you can savely assume that the implementation your
program runs under knows how to send arguments to functions it has to
call in a manner as if there were something you would call a stack
(even it is not such thing as a stack available), in a hosted
environment there will be something that works like a heap regardless
of there is something that is a heap or not and that the
implementation knows how to handle general purpose or special
registers if the implementation knows of such things.
Again: the abstract mashine knows nothing about register(s), stack(s),
heap(s) - it is on the implementation to use them if they exists.
--
Tschau/Bye
Herbert
Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2R Deutsch ist da!
Herbert Rosenau
wrote:
>
> C assumes a stack, and if the machine has no
> stack register it must be implemented in software.
Once more that the Naiva proves that he knows nothing about C.
No wounder that nobody trusts his commercial comiler.
> > The comment
> > I'm looking for is not what the standard prohibits in terms of
> > allegories.
> >
>
> The standard doesn't say it explicitely but the structure of
> the language assumes a stack.
>
> If main alls initialize, and initialize calls malloc we have
> a stack of
>
> main
> initialize
> malloc
No, there is no stack recommended.
> and when malloc finishes, the stack is popped and we are in
> initialize. When initialize is finished we pop the stack
> and we get into main again.
No, there is nothing popped! There are more architectures around than
I86 and other OSes than mickysoft windows and its assumes. GBut Naiva
is naive enough to think that nothing exept windows on I86 exists.
Sztop to blame yourself by posting in clc!
Stop spamkming for your properitayry commercial product!
Frank
> On 2009-10-12, Frank <mer...@lomas-assault.net> wrote:
>> Instead I'm trying to think of what might be useful, given that there
>> is an execution register, and that it amounts to a stack. Does C have
>> a function that changes what happens in the execution register?
>
> I don't think I understand. If you're wondering about breaking the
> calling sequence, consider setjmp()/longjmp().
These were the functions I was thinking of. We all understand that the
Standard says things and doesn't say things, and that this is one that it
says nothing about. I hope there will be no objections to topicality.
...and now that Han is back, I'll be interested in his opinion and
disappointed to read him giving himself as Keith.
That said, I'm fishing for an execution model that uses the above
functions. Don't worry, I don't know much about it. I have Plauger's _The
Standard C Library_ for reference.
P.J. must have been Heathfield's typing instructor :-)
--
Frank
Whining is anger through a small opening.
~~ Al Franken
Seebs
> That said, I'm fishing for an execution model that uses the above
> functions.
I think they've been used in at least some programs to try to implement
coroutines and the like.
Frank
Vielen Dank, Herbert.
Wie sagt man 'stack' auf Deutsch?
--
Frank
...................... o _______________ _,
` Good Morning! , /\_ _| | .-'_|
`................, _\__`[_______________| _| (_|
] [ \, ][ ][ (_|
Frank
> On 2009-10-12, Kenny McCormack <gaz...@shell.xmission.com> wrote:
>> Further, the hyper-literal minded, autistics/Asbergers patient types
>> here, don't do well with allegories.
>
> I am assured by people who apparently give a flying fuck that people
> treating patients with autism prefer the phrase "people with autism" to
> "autistics". The name of the syndrome, BTW, is "Asperger's".
>
> However, it is not necessarily the case that people with various
> autism-spectrum traits don't do well with allegories; if anything, many
> of them do exceptionally well with allegories, because they are conscious
> that the allegory is a tool for thinking about something, not the reality
> of the thing described.
>
>>They are, as I'm sure Kiki will
>> tell you by and by, best avoided.
>
> Doubtless. Certainly, if I were jealous of people who were much better
> at something than I, it would make sense for me to tell other people to
> avoid them.
>
> -s
I'm approximately as worried about kiki as I am texas right now. We have
differences.
--
Frank
Most of us here in the media are what I call infotainers...Rush Limbaugh is
what I call a disinfotainer. He entertains by spreading disinformation.
~~ Al Franken
Ben Pfaff
[setjmp, longjmp]
> That said, I'm fishing for an execution model that uses the above
> functions. Don't worry, I don't know much about it. I have Plauger's _The
> Standard C Library_ for reference.
Sometimes they're used for error handling, e.g. in libpng:
When libpng encounters an error, it expects to longjmp back to your
routine. Therefore, you will need to call setjmp and pass your
png_jmpbuf(png_ptr). If you read the file from different routines, you
will need to update the jmpbuf field every time you enter a new routine
that will call a png_*() function.
See your documentation of setjmp/longjmp for your compiler for more
information on setjmp/longjmp. See the discussion on libpng error han-
dling in the Customizing Libpng section below for more information on
the libpng error handling. If an error occurs, and libpng longjmp's
back to your setjmp, you will want to call png_destroy_read_struct() to
free any memory.
if (setjmp(png_jmpbuf(png_ptr)))
{
png_destroy_read_struct(&png_ptr, &info_ptr,
&end_info);
fclose(fp);
return (ERROR);
}
The page at http://www.freetype.org/david/reliable-c.html is a
"paper" that describes this kind of design technique.
--
"I don't have C&V for that handy, but I've got Dan Pop."
--E. Gibbons
Frank
Ok. Why are they unfavo(u)red?
Will you and PJ obligate yourselves one day to get an editor?
The criticism of writing is a tender place for some. Nichtsdestoweniger,
es bedarf dem(S) Autur(S) der Kleinenleser. Gru�,
--
Frank
It's easier to put on slippers than to carpet the whole world.
~~ Al Franken
Frank
> "I don't have C&V for that handy, but I've got Dan Pop."
> --E. Gibbons
i'LL READ THIS TOMORROW WITH FRESH EYES. MY GUESS IS THAT YOU TOOK FEWER
WOODEN OBJECTS IN YOUR EYES THAN I DID TODAY. CHEERS,
--
Frank
There's no liberal echo chamber in this country. There's a right-wing echo
chamber. I want to create a countervailing echo chamber.
~~ Al Franken, Chicago Tribune interview, on
Keith Thompson
[...]
> ...and now that Han is back, I'll be interested in his opinion and
> disappointed to read him giving himself as Keith.
What?
Keith Thompson
[...]
> I'm approximately as worried about kiki as I am texas right now. We have
> differences.
"Kiki" appears to be KM's deliberately offensive nickname for me.
I'll thank you not to use it.
Richard Heathfield
> In Dread Ink, the Grave Hand of Richard Heathfield Did Inscribe:
>
<snip>
>> It may
>> be that your question is one to which "setjmp/longjmp" might be a
>> sensible (or at least not totally nonsensical) answer. Having said
>> that, those are not two of my favourite functions.
>
> Ok. Why are they unfavo(u)red?
Personally, I don't like them because they screw up my mental model of
the code calling hierarchy. But just because I don't like them, that
doesn't mean other people don't like them - it seems that whenever I
get involved in a C project other than at the beginning, someone has
already managed to find a way to slip setjmp/longjmp into the mix, so
like them or not, I still have to know about them, alas.
> Will you and PJ obligate yourselves one day to get an editor?
I don't know what you mean here. "PJ" (by whom I am guessing that you
mean P J Plauger) will no doubt speak for himself if he wishes. As
for me, I already have several editors, of which the foremost is vim.
If you mean book editors, most technical books nowadays have several
editors - crosspondian publishers seem to use the term "editor" to
mean "employee who works on this book" with much the same carefree
abandon as "vice-president" is used by their co-nationals to mean
"employee in a middle or senior management capacity".
<snip>
Chris Dollin
> Chris Dollin <chris....@hp.com> writes:
>> Keith Thompson wrote:
>>> To be clear, there must be some stack-like (last-in first-out)
>>> data structure to implement the set of information necessary to keep
>>> track of the currently active set of function calls.
>>
>> Nitpick: only if there's some recursion. Otherwise each function can
>> have its own static area for storing locals & return addresses.
>>
>> If there's no recursion and no function-pointer variables, the compiler
>> could "just" inline everything!
>
> Meta-nitpick: In the abstract machine, the set of currently active
> function calls does behave in a last-in first-out manner, even if
> the implementation pre-allocates activation records and/or doesn't
> take any action to deallocate them when they're no longer active.
Yes.
> An implementation in which a non-recursive program has a statically
> allocated activation record for each function is just another example
> where a "stack" (in the abstract sense) is implemented by a method
> other than a classic contiguous hardware stack.
So much unlike a contiguous hardware stack that it's a nice counter-
example for "C programs need a stack", which is why I was pushing the
nitpick.
For further amusement, take the static areas for the function variables,
and then sort them by variable name or hash of same, so the "stack frames"
themselves are discontiguous.
--
"If time remained, the reasons would have rhymed." - IQ, /Frequency/
Hewlett-Packard Limited registered office: Cain Road, Bracknell,
registered no: 690597 England Berks RG12 1HN
Nick Keighley
> In <ooh15vgl4q35.ueitgdn9lkri$....@40tude.net>, Frank wrote:
> > In Dread Ink, the Grave Hand of Richard Heathfield Did Inscribe:
> >> It may
> >> be that your question is one to which "setjmp/longjmp" might be a
> >> sensible (or at least not totally nonsensical) answer. Having said
> >> that, those are not two of my favourite functions.
>
> > Ok. Why are they unfavo(u)red?
do you know what they do?
> Personally, I don't like them because they screw up my mental model of
> the code calling hierarchy.
How could this be! They're just an implentation of a continuation!
I'm always a bit nervous about what gets left-behind. As unlike C++
there is no automatic cleanup code invoked. So I'm nervous about malloc
()'d
memory and file handles and such like.
> But just because I don't like them, that
> doesn't mean other people don't like them - it seems that whenever I
> get involved in a C project other than at the beginning, someone has
> already managed to find a way to slip setjmp/longjmp into the mix, so
> like them or not, I still have to know about them, alas.
unlucky you. I havn't yet worked on a project that had them!
> > Will you and PJ obligate yourselves one day to get an editor?
have you been drinking from the same bottle as Tech07?
<snip>
--
> Callbacks are a form of continuation.
Yes, in the same sense that a shoe is a form of aircraft carrier.
jacob navia
>
> So much unlike a contiguous hardware stack that it's a nice counter-
> example for "C programs need a stack", which is why I was pushing the
> nitpick.
>
> For further amusement, take the static areas for the function variables,
> and then sort them by variable name or hash of same, so the "stack frames"
> themselves are discontiguous.
>
Sure sure. You can imagine what you want. It is worth noting that until
now a *single* implementation has been documented that implements
a software stack, for a very marginal processor that lacks a hardware one.
Nick Keighley
> [...] I'm fishing for an execution model that uses the [setjump/longjmp]
> functions.
poor mans exception handler
Chris Dollin
> Chris Dollin a �crit :
>>
>> So much unlike a contiguous hardware stack that it's a nice counter-
>> example for "C programs need a stack", which is why I was pushing the
>> nitpick.
>>
>> For further amusement, take the static areas for the function variables,
>> and then sort them by variable name or hash of same, so the "stack frames"
>> themselves are discontiguous.
>
> Sure sure.
Yeah, yeah.
> You can imagine what you want.
I already knew that.
> It is worth noting that until
> now a *single* implementation has been documented that implements
> a software stack, for a very marginal processor that lacks a hardware one.
I thought we had at least two relevant examples -- the IBM 360 et seq
(which don't have a "hardware stack") and the ARM (which doesn't have a
hardware-distinguished stack pointer register and for which the C compiler
uses a mixed strategy where stack frames (managed using the conventional
stack pointer & multi-word load-store instrautions) are allocated out
of stack chunks, which in turn are allocated from the C heap.
--
"Is there a reason this is written in iambic pentameter?" Marten,
/Questionable Content/
Hewlett-Packard Limited Cain Road, Bracknell, registered no:
registered office: Berks RG12 1HN 690597 England
jacob navia
> and the ARM (which doesn't have a
> hardware-distinguished stack pointer register and for which the C compiler
> uses a mixed strategy where stack frames (managed using the conventional
> stack pointer & multi-word load-store instrautions) are allocated out
> of stack chunks, which in turn are allocated from the C heap.
>
Sure sure. Please read the ARM architecture description. You are talking
nonsense.
And IBM 360 (maybe you did not know that) stopped being produced
at the beginning of the seventies, last century...
http://www.arm.com/pdfs/ARMv6_Architecture.pdf page 9
That architecture supports even multiple stacks.
But I have had my dose of this. I will not reply to
further remarks of this style.
Dik T. Winter
> In <ooh15vgl4q35.ueitgdn9lkri$.d...@40tude.net>, Frank wrote:
> > In Dread Ink, the Grave Hand of Richard Heathfield Did Inscribe:
> >> that, those are not two of my favourite functions.
> >
> > Ok. Why are they unfavo(u)red?
> > Will you and PJ obligate yourselves one day to get an editor?
>
> I don't know what you mean here.
I think Frank is criticising your use of British spelling. Interesting though
that his sentence would have improved considerably when its advise had been
followed on itself.
--
dik t. winter, cwi, science park 123, 1098 xg amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Nick Keighley
> Chris Dollin a écrit :
[machines without dedictaed hardware stacks]
> And IBM 360 (maybe you did not know that) stopped being produced
> at the beginning of the seventies, last century...
with a bit of googling:-
"The zSeries line succeeded the System/390 line (S/390 for short),
maintaining
full backward compatibility. In effect, zSeries machines are the
direct, lineal
descendants of System/360, announced in 1964, and the System/370 from
1970s.
Applications written for these systems can still run, unmodified,
with only
few exceptions, on the newest System z over four decades later."
bartc
>
> [machines without dedictaed hardware stacks]
>
>> And IBM 360 (maybe you did not know that) stopped being produced
>> at the beginning of the seventies, last century...
>
> with a bit of googling:-
>
> "The zSeries line succeeded the System/390 line (S/390 for short),
> maintaining
> full backward compatibility. In effect, zSeries machines are the
> direct, lineal
> descendants of System/360, announced in 1964, and the System/370 from
> 1970s.
> Applications written for these systems can still run, unmodified,
> with only
> few exceptions, on the newest System z over four decades later."
Without actually delving into the details, being backwards compatible
doesn't preclude the newer models from having hardware stacks.
Richard Heathfield
> In article <Qp6dnThm5-7EuUnX...@bt.com>
> r...@see.sig.invalid writes:
> > In <ooh15vgl4q35.ueitgdn9lkri$.d...@40tude.net>, Frank wrote:
> > > In Dread Ink, the Grave Hand of Richard Heathfield Did
> > > Inscribe:
> ...
> > >> that, those are not two of my favourite functions.
> > >
> > > Ok. Why are they unfavo(u)red?
> ...
> > > Will you and PJ obligate yourselves one day to get an editor?
> >
> > I don't know what you mean here.
>
> I think Frank is criticising your use of British spelling.
Oh, okay. Thanks for the interpretation. I note that, if "Frank"'s
recent posting history is anything to go by, his criticisms are not
terribly valuable.
Dik T. Winter
> Chris Dollin a �crit :
>
> > and the ARM (which doesn't have a
> > hardware-distinguished stack pointer register and for which the C compiler
> > uses a mixed strategy where stack frames (managed using the conventional
> > stack pointer & multi-word load-store instrautions) are allocated out
> > of stack chunks, which in turn are allocated from the C heap.
> >
>
> Sure sure. Please read the ARM architecture description. You are talking
> nonsense.
What is the hardware-distinguished stack pointer register of the ARM?
> And IBM 360 (maybe you did not know that) stopped being produced
> at the beginning of the seventies, last century...
What about the IBM 370, 390, Z-series?
Dik T. Winter
...
> > "The zSeries line succeeded the System/390 line (S/390 for short),
> > maintaining
> > full backward compatibility. In effect, zSeries machines are the
> > direct, lineal
> > descendants of System/360, announced in 1964, and the System/370 from
> > 1970s.
> > Applications written for these systems can still run, unmodified,
> > with only
> > few exceptions, on the newest System z over four decades later."
>
> Without actually delving into the details, being backwards compatible
> doesn't preclude the newer models from having hardware stacks.
S/390 certainly had no hardware stack the last time I looked in the
instruction set manual.
Chris Dollin
> Chris Dollin a �crit :
>
>> and the ARM (which doesn't have a
>> hardware-distinguished stack pointer register and for which the C compiler
>> uses a mixed strategy where stack frames (managed using the conventional
>> stack pointer & multi-word load-store instrautions) are allocated out
>> of stack chunks, which in turn are allocated from the C heap.
>
> Sure sure. Please read the ARM architecture description. You are talking
> nonsense.
I see you're referring to newer ARMs here. I'm afraid I haven't kept up
with the updates to the instruction set; as I remarked in earlier (MUCH
earlier) messages, I'm speaking from my experiences of many years ago.
My bad for not supplying that particular piece of context.
(As far as I can tell, the stack-handling referred to in that document
is for /interupts/, not normal C function calls. Gosh, and it looks
like they've added a bunch of unconditional instructions. Well, they did
say that condition NEV was to be treated with caution ...)
--
"I'm far too ditzy to grasp the subtleties of mockery." Raven,
/Questionable Content/
Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England
Chris Dollin
> And IBM 360 (maybe you did not know that) stopped being produced
> at the beginning of the seventies, last century...
You ignored the "et seq" in my message; the 360 left descendents.
--
"Common concerns such as property damage and wholesale Pintsize
destruction are of no concern to the king!" /Questionable Content/
Chris Dollin
While the new models might have acquired stacks, old code running on
them very likely doesn't use them, so they'd continue to be examples
of code that doesn't use hardware stacks.
--
"There is no need to linger." Kildas, /Year of the Unicorn/
bartc
>>
>>> and the ARM (which doesn't have a
>>> hardware-distinguished stack pointer register and for which the C
>>> compiler uses a mixed strategy where stack frames (managed using
>>> the conventional stack pointer & multi-word load-store
>>> instrautions) are allocated out
>>> of stack chunks, which in turn are allocated from the C heap.
>>>
>>
>> Sure sure. Please read the ARM architecture description. You are
>> talking nonsense.
>
> What is the hardware-distinguished stack pointer register of the ARM?
ARM processors and their reference manuals are not the easiest things to
find your way around. Nevertheless, from what I could figure out, ARM6 at
least seems to use R13 as a hardware stack pointer, subject to a bunch of
provisos, clauses and references which I was not inclined to follow
through.
(I feel sorry for those who have to program these things at low level. Is
nobody capable of making anything simple and elegant these days?)
Chris Dollin
> Dik T. Winter wrote:
>> What is the hardware-distinguished stack pointer register of the ARM?
>
> ARM processors and their reference manuals are not the easiest things to
> find your way around. Nevertheless, from what I could figure out, ARM6 at
> least seems to use R13 as a hardware stack pointer, subject to a bunch of
> provisos, clauses and references which I was not inclined to follow
> through.
However, R13 is no different in hardware to R0..R12 [1]; it is [certainly
in the ARM3] the "stack pointer" by software convention, rather than hardware
necessity. You can do pushy and poppy things with R3 just as well as with
R13.
[1] Not /quite/ true, in two ways which are both irrelevant, I think, to
the current discussion.
(a) it has number 13 rather than some other number. This makes a
difference to code that uses the load/store multiple instructions,
since the place it gets stored to will depend on which register
you pick; you can't just rename all the registers in your code,
you'll have to mess around with offsets too. It's /convenient/
that it's at the "end" of the "ordinary register" space, but were
it not, it would be only a minor inconvenience.
(b) it's a shadowed register; there's an R13 for each processor mode.
This matters for interrupt handling but not user code.
In contrast, R15 is very special, since it's the program counter, and
R14 is a little special, since it's the return-address register. Note
that it's special property is just that the return address gets written
to it on calls. [I think post-ARM3 this changes, to cope with full 32-
bit addressing; the "return address" used to combine the address and
the processor flags.]
--
"He touched the button over his heart." - James Blish, /A Clash of Cymbals/
Dik T. Winter
> Dik T. Winter wrote:
...
> > What is the hardware-distinguished stack pointer register of the ARM?
>
> ARM processors and their reference manuals are not the easiest things to
> find your way around. Nevertheless, from what I could figure out, ARM6 at
> least seems to use R13 as a hardware stack pointer, subject to a bunch of
> provisos, clauses and references which I was not inclined to follow
> through.
As far as I have been able to ascertain this is about interrupts.
> (I feel sorry for those who have to program these things at low level. Is
> nobody capable of making anything simple and elegant these days?)
The machine is not designed to be programmed at a low level. However, there
have been worse machines.
Joachim Schmitz
> Frank <fr...@example.invalid> writes:
> [...]
>> I'm approximately as worried about kiki as I am texas right now. We
>> have differences.
>
> "Kiki" appears to be KM's deliberately offensive nickname for me.
> I'll thank you not to use it.
While I accept that you don't like to be called Kiki, I fail to understand
why this is offensive?, mind to explain?
Bye, Jojo
REH
wrote:
> Keith Thompson wrote:
> While I accept that you don't like to be called Kiki, I fail to understand
> why this is offensive?, mind to explain?
>
You need a better reason than it's not his name, and it's a juvenile
attempt to antagonize him?
REH
jameskuyper
First of all, it's not his actual name, nor even a standard English
nickname for a name like Keith; that's enough in itself to suggest an
intent to be insulting.
Secondly, English nicknames ending in 'i' and 'y' tend to have
diminutive connotations, and are often used to refer to a lover, a
small child, or a pet. When the diminutive form is not clearly
intended as a joke (such as a nickname of "Tiny" for a huge man), the
connotation is often that it is the person's social status which is
diminutive, such as that of a pet relative to it's owner, or a child
relative to an adult, or (in sexist society) women relative to men.
This is often consider (and sometimes intended) to be offensive,
especially if the perception of low social status is not shared by the
person the nickname refers to.
Note the heavy use of weasel wording such as "tend", and "often" in
the above paragraph. The selection of such a nickname is not, in
itself, proof of an intent to insult. However, the single biggest
reason why this particular nickname is offensive is that KM has
tainted it by using it almost exclusively in contexts which make it
quite clear that the connotation of low status is intended.
Keith Thompson
It's almost certainly intended to be offensive. It's also not
my name. (I happen to dislike most nicknames that are derivatives
of my first name, but that's not really the point.)
Joachim Schmitz
Yes.
Bye, Jojo
Joachim Schmitz
OK, thanks for that explanation. Makes sense but is a bit weak IMHO.
Bye, Jojo
Keith Thompson
No, you don't.
To be clear, you certainly don't *need* to know why I dislike it.
I don't mind explaining it, as I've already done elsethread.
But surely the reasons cited by REH are good enough.
Joachim Schmitz
> "Joachim Schmitz" <nospa...@schmitz-digital.de> writes:
>> REH wrote:
>>> On Oct 13, 1:08 pm, "Joachim Schmitz"
>>> <nospam.j...@schmitz-digital.de> wrote:
>>>> Keith Thompson wrote:
>>>> While I accept that you don't like to be called Kiki, I fail to
>>>> understand why this is offensive?, mind to explain?
>>>
>>> You need a better reason than it's not his name, and it's a juvenile
>>> attempt to antagonize him?
>>
>> Yes.
>
> No, you don't.
Well, I do. It's not vital though...
> To be clear, you certainly don't *need* to know why I dislike it.
Right. But I need to know what is offensive about it.
> I don't mind explaining it, as I've already done elsethread.
> But surely the reasons cited by REH are good enough.
For disliking it yes, but I don't think this is enough to explain it's
offensiveness
Bye, Jojo
Joachim Schmitz
> "Joachim Schmitz" <nospa...@schmitz-digital.de> writes:
>> Keith Thompson wrote:
>>> Frank <fr...@example.invalid> writes:
>>> [...]
>>>> I'm approximately as worried about kiki as I am texas right now.
>>>> We have differences.
>>>
>>> "Kiki" appears to be KM's deliberately offensive nickname for me.
>>> I'll thank you not to use it.
>>
>> While I accept that you don't like to be called Kiki, I fail to
>> understand why this is offensive?, mind to explain?
>
> It's almost certainly intended to be offensive. It's also not
> my name. (I happen to dislike most nicknames that are derivatives
> of my first name, but that's not really the point.)
Rumsfeld meant to offend us (the Germans and the Frensh, mainly) when
calling us 'the old Europe' (because we refused to go to war with Irak). The
majority here didn't find that offensive at all but felt honoured instead.
So intention is not enough to explain why you find it offensive.
Whatever. let's leave it at that, I just thought, as not being a native
english speaker, I migh be missing some obvious connotation. Apparently I'm
not.
Bye, Jojo
Kenny McCormack
How do you know (what makes you think) it is an attempt to antagonize him ?
How do you know (what makes you think) it is juvenile ?
David Resnick
wrote:
> In article <838b1316-772b-4eef-a054-2861f071a...@z34g2000vbl.googlegroups.com>,
>
> REH <spamj...@stny.rr.com> wrote:
> >On Oct 13, 1:08 pm, "Joachim Schmitz" <nospam.j...@schmitz-digital.de>
> >wrote:
> >> Keith Thompson wrote:
> >> While I accept that you don't like to be called Kiki, I fail to understand
> >> why this is offensive?, mind to explain?
>
> >You need a better reason than it's not his name, and it's a juvenile
> >attempt to antagonize him?
>
> >REH
>
> How do you know (what makes you think) it is an attempt to antagonize him ?
> How do you know (what makes you think) it is juvenile ?
The source.
-David
Keith Thompson
Ok, now I'm curious. *Why* do you need to know? What difference
could it possibly make to you?
The phrase "need to know" usually implies something more than
curiosity, for example that you have a real need to do something,
or refrain from doing something, based on the information.
To clarify my earlier remarks a bit, what I wrote previously was:
"Kiki" appears to be KM's deliberately offensive nickname for me.
What I meant, I suppose, was that KM intended it to be offensive (an
assumption, but a safe one), not that the name itself is inherently
offensive (it certainly wouldn't be if that were really my name).
I could have expressed myself more clearly, but I didn't think
it was that important. (I don't much care what KM says about me,
but I'd rather not see others pick up his annoying habits.)
James Dow Allen
wrote:
> On 13 Oct, 06:42, Frank <fr...@example.invalid> wrote:
>
> > [...] I'm fishing for an execution model that uses the [setjump/longjmp]
> > functions.
>
> poor mans exception handler
It can also be used as a carefree man's backtracker as at
http://james.fabpedigree.com/rrome.htm
where the calls occur from the following macros:
#define EITHER if (S[1] = S[0], ! setjmp((S++)->jb)) {
#define OR } else EITHER
#define REJECT longjmp((--S)->jb, 1)
#define END_EITHER } else REJECT;
James Dow Allen
Default User
> While I accept that you don't like to be called Kiki, I fail to
> understand why this is offensive?, mind to explain?
Besides what the others have mentioned, in English-speaking countries
it's generally a female name.
Brian
--
Day 253 of the "no grouchy usenet posts" project
Peter Nilsson
> But I need to know what is offensive about it.
Then look up what it means in Filipino.
--
Peter
Seebs
> Right. But I need to know what is offensive about it.
Why?
Seriously, who cares? Maybe it's offensive because he used to like Sluggy
Freelance but now he hates it. Who cares? It's offensive.
-s
--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
Richard
> On 2009-10-13, Joachim Schmitz <nospa...@schmitz-digital.de> wrote:
>> Right. But I need to know what is offensive about it.
>
> Why?
>
> Seriously, who cares? Maybe it's offensive because he used to like Sluggy
> Freelance but now he hates it. Who cares? It's offensive.
>
> -s
No it isn't. It's a nickname.
--
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c
robert...@yahoo.com
> Chris Dollin <chris.dol...@hp.com> writes:
> >Nitpick: only if there's some recursion. Otherwise each function can
> >have its own static area for storing locals & return addresses.
>
> There is another case, where this will not work:
>
> When there are many functions with a huge size of
> automatic storage, but during each run of the program
> only one of them is being called.
>
> With memory allocation at run-time only the memory
> for the one function called will be allocated, which
> might still fit into available memory.
>
> When automatic memory is allocated statically once for
> every function, the total amount of memory allocated
> might exceed memory limitations.
While that's true, and might be a problem in some cases, it doesn't
invalidate the scheme. You just have a QoI issue where the static
allocation of your program is larger than you'd hope for. Nor is it
necessarily a problem - if these functions with huge automatic
allocations are all leaf functions (or otherwise guaranteed not to be
in each other's call chains), it would be trivial for the compiler to
share a static area for the automatics for all of those functions.
And then there's the flip side - stacks are often much, much smaller
than the possible static area, and functions that have "huge"
automatic areas tend not to fit well on the stack, which will might
them fail in any case. On the third hand, some compilers will
allocate excessively large automatic areas on the heap, which solves
the problem in either case.
user923005
Maybe he doesn't like Ernest Maurice Vandeweghe III.
Perhaps you would like it if I called you "Jochie-poo" or perhaps you
would find it offensive.
If I started calling you that, and you said you didn't like it, I
would not require an explanation.
robert...@yahoo.com
> Nick Keighley wrote:
> > On 13 Oct, 12:20, jacob navia <ja...@nospam.org> wrote:
>
> > [machines without dedictaed hardware stacks]
>
> >> And IBM 360 (maybe you did not know that) stopped being produced
> >> at the beginning of the seventies, last century...
>
> > with a bit of googling:-
>
> > "The zSeries line succeeded the System/390 line (S/390 for short),
> > maintaining
> > full backward compatibility. In effect, zSeries machines are the
> > direct, lineal
> > descendants of System/360, announced in 1964, and the System/370 from
> > 1970s.
> > Applications written for these systems can still run, unmodified,
> > with only
> > few exceptions, on the newest System z over four decades later."
>
> Without actually delving into the details, being backwards compatible
For ordinary program use they still do not.
The closest thing is the linkage stack, which is used with a call-gate-
like mechanism to allow transfers of control between different
applications, including calls between different address spaces. The
linkage stack itself is protected from the applications (although the
application can use a specific instruction to put some data into a
linkage stack entry to facilitate parameter passing), and is not a
single contiguous structure (it's a linked list of areas no more than
about 64KB each).
While you could abuse the linkage stack and use it for ordinary
function calls, it's very heavyweight (not least, each stack entry is
296 bytes), and would perform very badly for that purpose. Nor do the
typical OS's usually set up a large linkage stack by default (rather
as stack full exceptions occur, they extend the linked list of stack
spaces).
Ben Bacarisse
Just a word of warning: the behaviour of the above is undefined due to
the severe limits placed on the way setjmp can be called.
Basically you can have nothing more complex than !setjmp(...) or
setjmp [relational or equality op] [integer constant expression] as
the controlling expression of an if/switch/while/for/do.
--
Ben.
Seebs
> No it isn't. It's a nickname.
Non sequitur.
Something is offensive if it offends. Being a "nickname" does not make
something magically inoffensive.
But, since you seem to want to play, let's go explain the details.
Nicknames are used as a social signal. In general, nicknames can be
either friendly or unfriendly. A friendly nickname is used to denote
closeness or affection. An unfriendly nickname is used to denote hostility
or derision.
It is not always possible to tell, just looking at the nickname, which
is which. However, there is a useful pattern: If someone responds
negatively to a nickname, its continued use is absolutely,
unambiguously, unfriendly.
Given that, we can certainly and reasonably assert that the continued use
of the nickname is hostile and intended to be offensive, and that it is
reasonable for Keith to treat it as a willful intent.
It is, of course, theoretically possible that there could be a circumstance
in which someone was continuing to use a disliked nickname without hostile
intent, but in a case where it is coupled with other derisive or hostile
remarks and behaviors, there's really no practical ambiguity. Spend your
time worrying about SHA1 checksum clashes, they're more likely.
Keith Thompson
[...]
> It is not always possible to tell, just looking at the nickname, which
> is which. However, there is a useful pattern: If someone responds
> negatively to a nickname, its continued use is absolutely,
> unambiguously, unfriendly.
For the record, I'm not aware of anyone having used this nickname
after I expressed my dislike for it.
Nick Keighley
wrote:
> Keith Thompson wrote:
> > "Joachim Schmitz" <nospam.j...@schmitz-digital.de> writes:
> >> REH wrote:
> >>> On Oct 13, 1:08 pm, "Joachim Schmitz"
> >>> <nospam.j...@schmitz-digital.de> wrote:
> >>>> Keith Thompson wrote:
> >>>> While I accept that you don't like to be called Kiki, I fail to
> >>>> understand why this is offensive?, mind to explain?
> >>> You need a better reason than it's not his name, and it's a juvenile
> >>> attempt to antagonize him?
>
> >> Yes.
>
> > No, you don't.
>
> Well, I do. It's not vital though...
>
> > To be clear, you certainly don't *need* to know why I dislike it.
>
> Right. But I need to know what is offensive about it.
?? if someone uses a name for him that he dislikes and only uses to
cause
offense then isn't almost by definition offensive?
I mean this is playgound stuff shouldn't we have grown out of this
sort of
thing?
And *why* do you need to know why its offensive? Surely Keith's
dislike
of it it enough for a polite and reasonable person to desist using it.
Frank
> Frank <fr...@example.invalid> writes:
> [...]
>> I'm approximately as worried about kiki as I am texas right now. We have
>> differences.
>
> "Kiki" appears to be KM's deliberately offensive nickname for me.
> I'll thank you not to use it.
How's Chuck?
--
Frank
The biases the media has are much bigger than conservative or liberal.
They're about getting ratings, about making money, about doing stories that
are easy to cover.
~~ Al Franken,
Frank
> In <KrGA5...@cwi.nl>, Dik T. Winter wrote:
>
>> In article <Qp6dnThm5-7EuUnX...@bt.com>
>> r...@see.sig.invalid writes:
>> > In <ooh15vgl4q35.ueitgdn9lkri$.d...@40tude.net>, Frank wrote:
>> > > In Dread Ink, the Grave Hand of Richard Heathfield Did
>> > > Inscribe:
>> ...
>> > >> that, those are not two of my favourite functions.
>> > >
>> > > Ok. Why are they unfavo(u)red?
>> ...
>> > > Will you and PJ obligate yourselves one day to get an editor?
>> >
>> > I don't know what you mean here.
>>
>> I think Frank is criticising your use of British spelling.
>
> Oh, okay. Thanks for the interpretation. I note that, if "Frank"'s
> recent posting history is anything to go by, his criticisms are not
> terribly valuable.
>
> <snip>
Ohmiheck. Would you care to pick a page number for _C Unleashed_ and have
me tell you the proximity of typing errors?
Do you think that an integer exists, such that I can't find a typo within
15 pages?
Oh and remember--you can't read.
--
Frank
When you encounter seemingly good advice that contradicts other seemingly
good advice, ignore them both.
~~ Al Franken,
Joachim Schmitz
Curiosity is a strong motive. Without it no progress would be made at all.
> To clarify my earlier remarks a bit, what I wrote previously was:
>
> "Kiki" appears to be KM's deliberately offensive nickname for me.
>
> What I meant, I suppose, was that KM intended it to be offensive (an
> assumption, but a safe one), not that the name itself is inherently
> offensive (it certainly wouldn't be if that were really my name).
OK, understood now. Guess I was reading to much into it
Bye, Jojo
Joachim Schmitz
I certainly wouldn't like it, but I would find it offensive.
I'd ask you to stop using it.
I'd indeed find it offensive if you'd continue to use it.
> If I started calling you that, and you said you didn't like it, I
> would not require an explanation.
I wasn't asking why Keith doesn't like it, just why he found it offensive
Bye, Jojo
Joachim Schmitz
> On 13 Oct, 20:45, "Joachim Schmitz" <nospam.j...@schmitz-digital.de>
> wrote:
>> Keith Thompson wrote:
>>> "Joachim Schmitz" <nospam.j...@schmitz-digital.de> writes:
>>>> REH wrote:
>>>>> On Oct 13, 1:08 pm, "Joachim Schmitz"
>>>>> <nospam.j...@schmitz-digital.de> wrote:
>>>>>> Keith Thompson wrote:
>
>>>>>> While I accept that you don't like to be called Kiki, I fail to
>>>>>> understand why this is offensive?, mind to explain?
>
>>>>> You need a better reason than it's not his name, and it's a
>>>>> juvenile attempt to antagonize him?
>>
>>>> Yes.
>>
>>> No, you don't.
>>
>> Well, I do. It's not vital though...
>>
>>> To be clear, you certainly don't *need* to know why I dislike it.
>>
>> Right. But I need to know what is offensive about it.
>
> ?? if someone uses a name for him that he dislikes and only uses to
> cause
> offense then isn't almost by definition offensive?
Almost, possibly
> I mean this is playgound stuff shouldn't we have grown out of this
> sort of
> thing?
>
> And *why* do you need to know why its offensive? Surely Keith's
> dislike
> of it it enough for a polite and reasonable person to desist using it.
I think I explaind at length. Yes repeated use despite an expressed dislike
is offensive.
The nickname itself seems not, and I seeked clarification about that, no
more.
Bye, Jojo
Joachim Schmitz
Well, the next time you use it, we know for sure.
Bye, Jojo
Joachim Schmitz
> Joachim Schmitz wrote:
>
>> While I accept that you don't like to be called Kiki, I fail to
>> understand why this is offensive?, mind to explain?
>
> Besides what the others have mentioned, in English-speaking countries
> it's generally a female name.
Hmm, here too (but not exclisivly), but I think females might be offended of
you to think of a female nicknames to be offensive...
Bye, Jojo
bartc
"Joachim Schmitz" <nospa...@schmitz-digital.de> wrote in message
news:hb40t9$7b4$1...@online.de...
You just don't seem to get it. What exactly do you have to call somebody in
public, in your part of the world, to belittle them and show contempt and
disrespect?
--
Bartc
Nick Keighley
wrote:
applying a female name to a male person might quite well be offensive
to the male person.
Are you from Mars or something?
James Kuyper
It's somewhat sexist that using a feminine nickname for someone is a way
"to belittle them and show contempt and disrespect". Which is not to say
this isn't true - we do live in a sexist society.
The key point is that KM routinely displayed contempt and disrespect
when using this nickname, which tends to remove any reasonable doubts
about whether it was intended to be contemptuous and disrespectful.
Richard Heathfield
<snip>
> The key point is that KM routinely displayed contempt and disrespect
When was the last time he displayed even the slightest interest in C
programming? If ever? The group wastes a lot of its time being
distracted by irrelevant non-entities such as KM, AT, and RNSN. I
suggest that this time would be better spent discussing (or even
actually using!) the C language.
<snip>
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within
James Kuyper
> In Dread Ink, the Grave Hand of Richard Heathfield Did Inscribe:
>
>> In <KrGA5...@cwi.nl>, Dik T. Winter wrote:
>>
>>> In article <Qp6dnThm5-7EuUnX...@bt.com>
>>> r...@see.sig.invalid writes:
>>> > In <ooh15vgl4q35.ueitgdn9lkri$.d...@40tude.net>, Frank wrote:
>>> > > In Dread Ink, the Grave Hand of Richard Heathfield Did
>>> > > Inscribe:
>>> ...
>>> > >> that, those are not two of my favourite functions.
>>> > >
>>> > > Ok. Why are they unfavo(u)red?
...
>> Oh, okay. Thanks for the interpretation. I note that, if "Frank"'s
>> recent posting history is anything to go by, his criticisms are not
>> terribly valuable.
> Ohmiheck. Would you care to pick a page number for _C Unleashed_ and have
> me tell you the proximity of typing errors?
Well, if you consider "favourite" to be a typing error, I'm sure you'll
find lots of them in any book written in British English. That would
tell us more about your ignorance than about the quality of the
proofreading.
Ben Bacarisse
> Do you think that an integer exists, such that I can't find a typo within
> 15 pages?
-48,562?
--
Ben.
Joachim Schmitz
That's not what Brian said (but might well have been what he meant)
> Are you from Mars or something?
Not quite. I just deliberatly took Brian by what he said and forgot to add a
smiley...
Bye, Jojo
Richard
In all of the technical groups I read, only YOU are incapable of setting
your newsread properly. Why is that Nick? An attempt to be different?
>
>> > I don't mind explaining it, as I've already done elsethread.
>> > But surely the reasons cited by REH are good enough.
>>
>> For disliking it yes, but I don't think this is enough to explain it's
>> offensiveness
>
--
Tim Rentsch
> bartc wrote:
>>
>> "Joachim Schmitz" <nospa...@schmitz-digital.de> wrote in message
>> news:hb40t9$7b4$1...@online.de...
>>> Default User wrote:
>>>> Joachim Schmitz wrote:
>>>>
>>>>> While I accept that you don't like to be called Kiki, I fail to
>>>>> understand why this is offensive?, mind to explain?
>>>>
>>>> Besides what the others have mentioned, in English-speaking countries
>>>> it's generally a female name.
>>>
>>> Hmm, here too (but not exclisivly), but I think females might be
>>> offended of you to think of a female nicknames to be offensive...
>>
>> You just don't seem to get it. What exactly do you have to call
>> somebody in public, in your part of the world, to belittle them and
>> show contempt and disrespect?
>
> It's somewhat sexist that using a feminine nickname for someone is a
> way "to belittle them and show contempt and disrespect". [snip]
ISTM that any deliberately mis-applied label frequently offers an
implicit slur. It isn't sexist to observe that often people use a
feminine nickname with the intention of belittling and showing
contempt; what is sexist is using a feminine nickname in such a
way. IME most listeners are responding more to the attitudes of
the speaker than they are to any inherent prejudices of their own.
Moi
> The page at http://www.freetype.org/david/reliable-c.html is a "paper"
> that describes this kind of design technique.
Excellent stuff.
Thanks for the link, Ben,
AvK
James Dow Allen
> James Dow Allen <jdallen2...@yahoo.com> writes:
> > It can also be used as a carefree man's backtracker as at
> > http://james.fabpedigree.com/rrome.htm
> > where the calls occur from the following macros:
>
> > #define EITHER if (S[1] = S[0], ! setjmp((S++)->jb)) {
> > #define OR } else EITHER
> > #define REJECT longjmp((--S)->jb, 1)
> > #define END_EITHER } else REJECT;
>
> Just a word of warning: the behaviour of the above is undefined due to
> the severe limits placed on the way setjmp can be called.
Thanks for this, Ben! Although the code *does*
seem to work on at least a few different platforms,
I've wondered whether this might just be a lucky
happenstance due in part to the fact that the
function is otherwise rather tame.
>
> Basically you can have nothing more complex than !setjmp(...) or
> setjmp [relational or equality op] [integer constant expression] as
> the controlling expression of an if/switch/while/for/do.
One simple change I could make would be to
move the comma operator to inside the setjmp
argument, i.e. replace
if (S[1] = S[0], ! setjmp((S++)->jb)) {
with
if (! setjmp((S[1] = S[0], (S++)->jb))) {
Would this solve the problem?
The comma operator isn't just a fetish here,
but seemed essential to the "smoothness" of
these macros in the presence of "else".
If we insist, for some reason, on not using
the comma operator *at all*, a workaround may
be harder, assuming we reject an approach like:
/* which END_EITHER to use depends on number of OR's */
#define END_E1 } else REJECT; }
#define END_E2 } else REJECT; }}
#define END_E3 } else REJECT; }}}
#define END_E4 } else REJECT; }}}}
#define END_E5 } else REJECT; }}}}}
#define END_E6 } else REJECT; }}}}}}
Perhaps there's a clever solution based on some
" do { ... break ...} while()" construct, but I'll
leave that as an exercise. :-)
Another interesting puzzle -- solution for which
would be embarrassing for me, but perhaps not overly
surprising -- is to redesign the macros to avoid
setjmp/longjmp altogether. (I would not consider a
solution "valid" in this sense if its overall
complexity increases, or if threads or fork()s
are substituted for the setjmp()s.)
Feel free to deprecate my code! Much of my C coding
is for my own amusement; code I've delivered to
paying customers has never been this bizarre.
> Ben.
James Dow Allen
Nick Keighley
> Nick Keighley <nick_keighley_nos...@hotmail.com> writes:
> > And *why* do you need to know why its offensive? Surely Keith's
> > dislike
> > of it it enough for a polite and reasonable person to desist using it.
>
> In all of the technical groups I read, only YOU are incapable of setting
> your newsread properly. Why is that Nick? An attempt to be different?
to my knowledge google provides no automatic way to do this.
I think I've told you this before...
Richard
Then don't post using google. It corrupts the threads.
Others seem to manage btw.
*shrug*
Keith Thompson
Drop the comma operator and you're probably right.
Default User
Not really, as the reverse can be true as well. Regardless, calling
someone by a name they don't want you to use is rude.
Brian
--
Day 254 of the "no grouchy usenet posts" project
Seebs
> Hmm, here too (but not exclisivly), but I think females might be offended of
> you to think of a female nicknames to be offensive...
Most people think a gendered nickname inappropriate for their gender is
offensive. It's not whether it's male or female that's offensive, it's
that it's wrong.
Phil Carmody
And if it's not intended to be female, it's a cradle reduplication,
and thus implicitly diminutive and thus disrespectful.
It's just another one of his inane ticks. That's what killfiles
were invented for.
Phil
--
Any true emperor never needs to wear clothes. -- Devany on r.a.s.f1
Keith Thompson
> On 2009-10-14, Joachim Schmitz <nospa...@schmitz-digital.de> wrote:
>> Hmm, here too (but not exclisivly), but I think females might be
>> offended of you to think of a female nicknames to be offensive...
>
> Most people think a gendered nickname inappropriate for their gender is
> offensive. It's not whether it's male or female that's offensive, it's
> that it's wrong.
I suggest that we've spent more than enough time on this.
robert...@yahoo.com
wrote:
> On 13 Oct, 20:45, "Joachim Schmitz" <nospam.j...@schmitz-digital.de>
> wrote:
>
>
>
>
>
> > Keith Thompson wrote:
> > > "Joachim Schmitz" <nospam.j...@schmitz-digital.de> writes:
> > >> REH wrote:
> > >>> On Oct 13, 1:08 pm, "Joachim Schmitz"
> > >>> <nospam.j...@schmitz-digital.de> wrote:
> > >>>> While I accept that you don't like to be called Kiki, I fail to
> > >>>> understand why this is offensive?, mind to explain?
> > >>> attempt to antagonize him?
>
> > >> Yes.
>
> > > No, you don't.
>
> > Well, I do. It's not vital though...
>
> > > To be clear, you certainly don't *need* to know why I dislike it.
>
> > Right. But I need to know what is offensive about it.
>
> ?? if someone uses a name for him that he dislikes and only uses to
> cause
> offense then isn't almost by definition offensive?
>
> I mean this is playgound stuff shouldn't we have grown out of this
> sort of
> thing?
>
> dislike
> of it it enough for a polite and reasonable person to desist using it.
At least once in the last few years I was told by someone that A
called B an "X," and I did not know what the term "X" meant. As it
turned out, it was a regional racial epithet which I had never heard
before. This puts the comment in a completely different light than
calling someone by a (disliked) diminutive of their name (which you
might also not be familiar with - for example, many non-native English
speakers are probably unaware of the common reduction of "Richard").
I interpreted the original query as to why the term was offensive in
that context.
Default User
> I suggest that we've spent more than enough time on this.
Agreed. Sorry for helping to extend.
Ben Bacarisse
> On Oct 14, 5:14 am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>> James Dow Allen <jdallen2...@yahoo.com> writes:
>> > It can also be used as a carefree man's backtracker as at
>> > http://james.fabpedigree.com/rrome.htm
>> > where the calls occur from the following macros:
>>
>> > #define EITHER if (S[1] = S[0], ! setjmp((S++)->jb)) {
>> > #define OR } else EITHER
>> > #define REJECT longjmp((--S)->jb, 1)
>> > #define END_EITHER } else REJECT;
<snip>
>> Basically you can have nothing more complex than !setjmp(...) or
>> setjmp [relational or equality op] [integer constant expression] as
>> the controlling expression of an if/switch/while/for/do.
>
> One simple change I could make would be to
> move the comma operator to inside the setjmp
> argument, i.e. replace
> if (S[1] = S[0], ! setjmp((S++)->jb)) {
> with
> if (! setjmp((S[1] = S[0], (S++)->jb))) {
>
> Would this solve the problem?
I am pretty sure that that is fine. You have to take care with
automatic objects as well, but that is another issue. I think S has
static storage duration in the linked code.
> The comma operator isn't just a fetish here,
> but seemed essential to the "smoothness" of
> these macros in the presence of "else".
> If we insist, for some reason, on not using
> the comma operator *at all*, a workaround may
> be harder, assuming we reject an approach like:
> /* which END_EITHER to use depends on number of OR's */
> #define END_E1 } else REJECT; }
> #define END_E2 } else REJECT; }}
> #define END_E3 } else REJECT; }}}
> #define END_E4 } else REJECT; }}}}
> #define END_E5 } else REJECT; }}}}}
> #define END_E6 } else REJECT; }}}}}}
> Perhaps there's a clever solution based on some
> " do { ... break ...} while()" construct, but I'll
> leave that as an exercise. :-)
>
> Another interesting puzzle -- solution for which
> would be embarrassing for me, but perhaps not overly
> surprising -- is to redesign the macros to avoid
> setjmp/longjmp altogether. (I would not consider a
> solution "valid" in this sense if its overall
> complexity increases, or if threads or fork()s
> are substituted for the setjmp()s.)
That's an interesting problem. I suspect the co-routines are the best
way in an imperative, single-threaded, language and setjmp/longjmp are
a poor man's co-routine.
<snip>
--
Ben.
Seebs
> I suggest that we've spent more than enough time on this.
Probably. I am sympathetic to people trying to figure out where the offense
came from when it's not completely overt, because I have had a hard time
with that in the past. Still do sometimes!