subroutine stack and C machine model

[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]

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]

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...

 

[Keith Thompson]

-48,562?

Drop the comma operator and you're probably right.

 

[Default User]

Hmm, here too (but not exclisivly), but I think females might be
offended of you to think of a female nicknames to be offensive...

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

 

[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.

-s

 

[Phil Carmody]

applying a female name to a male person might quite well be offensive
to the male person.

Are you from Mars or something?

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

 

[Keith Thompson]

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.

 

[robertwessel2]

?? 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.

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.



Brian

 

[Ben Bacarisse]

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;

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>

 

[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!

-s

 

[Squeamizh]

to my knowledge google provides no automatic way to do this.
I think I've told you this before...

Are you posting through Google Groups? So am I, but I don't have the
same problem. For example, this paragraph is one long line without
any line breaks, and it probably looks fine.

Are you typing your posts in some other program and putting your own
linebreaks in it or something?

 

[luserXtrog]

Are you posting through Google Groups?  So am I, but I don't have the
same problem.  For example, this paragraph is one long line without
any line breaks, and it probably looks fine.

Are you typing your posts in some other program and putting your own
linebreaks in it or something?

I use google groups and break lines manually.
Sometimes a different width helps to hug the
sentences better. [Unfortunately, i/I]t can become quite a pain
to adjust later when fixing typos and thinkos.

Difficulty builds character.

 

[Joachim Schmitz]

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.

Indeed exactly that was my intention. Apologies that I apparently didn't
make myself clear enough and lead to this rather lengthy discussion.

bye, Jojo

 

[Joachim Schmitz]

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!

Thanks, that exactly was my intention. Apologies that I apparently didn't
make myself clear enough and lead to this rather lengthy discussion.

Bye, Jojo

 

[Nick Keighley]

Are you posting through Google Groups?  So am I, but I don't have the
same problem.  For example, this paragraph is one long line without
any line breaks, and it probably looks fine.

Are you typing your posts in some other program and putting your own
linebreaks in it or something?

I'm typeing directly into google and putting my own line breaks in.

aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa
aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa
aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa
aaaa aaaa

the above was typed as a single line

 

[James Kuyper]

I'm typeing directly into google and putting my own line breaks in.

That's your mistake. You're putting in too many line breaks; only break
the line manually at the end of paragraphs.

 

[Nick Keighley]

That's your mistake. You're putting in too many line breaks; only break
the line manually at the end of paragraphs.

ah, and as I observed above it breaks correctly. OMG

 

[Kenny McCormack]

Frank a écrit :

C assumes a stack, and if the machine has no
stack register it must be implemented in software.

Uh oh...