Can somebody interpret this for me?

   while (TRUE) { cont = (*cont)(); }

What on earth...?

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Invisible wrote:
> Can somebody interpret this for me?
> 
>   while (TRUE) { cont = (*cont)(); }
> 
> What on earth...?

cont is a pointer to a function that is expected to return a pointer to 
a function.  The code here causes a series of functions to be called, 
each one specifying another function to be called afterwards by 
returning the address of the function to be called.

Regards,
John

Post a reply to this message

>> Can somebody interpret this for me?
>>
>>   while (TRUE) { cont = (*cont)(); }
>>
>> What on earth...?
> 
> cont is a pointer to a function that is expected to return a pointer to 
> a function.  The code here causes a series of functions to be called, 
> each one specifying another function to be called afterwards by 
> returning the address of the function to be called.

Ah, so it *is* possible to read C? :-)

So cont points to a zero-argument function that returns a zero-argument 
function? And this loop just calls it repeatedly?

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

John VanSickle a écrit :
> Invisible wrote:
>> Can somebody interpret this for me?
>>
>>   while (TRUE) { cont = (*cont)(); }
>>
>> What on earth...?
> 
> cont is a pointer to a function that is expected to return a pointer to 
> a function.  The code here causes a series of functions to be called, 
> each one specifying another function to be called afterwards by 
> returning the address of the function to be called.
> 

I was thinking the same, but I can't seem to find the right type 
definition to make it work without casting to and from void*... Which is 
apparently illegal 
(http://www.parashift.com/c++-faq-lite/pointers-to-members.html#faq-33.8)

Here's what I ended up with:

typedef void* (*pfunc)();

void* test1()
{
     return (void*)test1;
}

int main()
{
     pfunc cont = test1;
     while (true) { cont = (pfunc)(*cont)(); }
     return 0;
}

I'd like to write:

typedef pfunc (*pfunc)();

pfunc test1()
{
     return test1;
}

int main()
{
     pfunc cont = test1;
     while (true) { cont = (*cont)(); }
     return 0;
}

But the typedef here does not seem to work. I can't say I blame the 
compiler for choking on that one either :-)

I'm not too comfortable with function pointers though, so it's likely 
that I'm missing something here... Any hints?

-- 
Vincent

Post a reply to this message

>> cont is a pointer to a function that is expected to return a pointer 
>> to a function.  The code here causes a series of functions to be 
>> called, each one specifying another function to be called afterwards 
>> by returning the address of the function to be called.
>>
> 
> I was thinking the same, but I can't seem to find the right type 
> definition to make it work without casting to and from void*... Which is 
> apparently illegal 

This is example code, so it might not be literally runnable... (It might 
be simplified somewhat.)

> I'm not too comfortable with function pointers though, so it's likely 
> that I'm missing something here... Any hints?

Don't look at me! ;-)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Invisible a écrit :
>>> cont is a pointer to a function that is expected to return a pointer 
>>> to a function.  The code here causes a series of functions to be 
>>> called, each one specifying another function to be called afterwards 
>>> by returning the address of the function to be called.
>>>
>>
>> I was thinking the same, but I can't seem to find the right type 
>> definition to make it work without casting to and from void*... Which 
>> is apparently illegal 
> 
> This is example code, so it might not be literally runnable... (It might 
> be simplified somewhat.)
> 

Does it still provide the declaration of cont, by any chance?

-- 
Vincent

Post a reply to this message

On Thu, 24 Jul 2008 14:24:51 +0200, Vincent Le Chevalier  
<gal### [at] libertyallsurfspamfr> wrote:
> I was thinking the same, but I can't seem to find the right type  
> definition to make it work without casting to and from void*... Which is  
> apparently illegal  
> (http://www.parashift.com/c++-faq-lite/pointers-to-members.html#faq-33.8)

It is illegal because a 'void *' is a data pointer, not a function pointer.

On a related note, we do not know if the original code was supposed to be  
standards-compliant or not, nor if it was supposed to be C or C++.


> Here's what I ended up with:
[...snipped...]

The "right" way to do it, assuming C++:
http://www.gotw.ca/gotw/057.htm



-- 
FE

Post a reply to this message

Fredrik Eriksson wrote:

> On a related note, we do not know if the original code was supposed to 
> be standards-compliant or not, nor if it was supposed to be C or C++.

Ment to be ANSI C (not C++).

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Invisible wrote:
> So cont points to a zero-argument function that returns a zero-argument 
> function? And this loop just calls it repeatedly?

Assuming TRUE is a value that always returns non-zero, yes. The code itself
appears to implement a state machine.

Of course, this being C, 'TRUE' could be a macro that expands to a function
 that returns a value and thus the loop need not be infinite. It could even
expand to a variable with a decrement or increment operator. Or really
anything - if the code were presented to someone as part of an computer
science exam, for example, they would probably be expected to pick that
possibility up. In the real world, no programmer would ever do something
that mean with a macro called TRUE. Right? :-)

-- Chris

Post a reply to this message

>> So cont points to a zero-argument function that returns a zero-argument 
>> function? And this loop just calls it repeatedly?
> 
> Assuming TRUE is a value that always returns non-zero, yes. The code itself
> appears to implement a state machine.

More exactly: It's a workaround for C's lack of lack of GOTO.

[This fragment appears in the output of a compiler that's using C as 
"portable assembly".]

> In the real world, no programmer would ever do something
> that mean with a macro called TRUE. Right? :-)

Hey, I found this cool site, it's called The Daily WTF... ;-)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Fredrik Eriksson a écrit :
> On Thu, 24 Jul 2008 14:24:51 +0200, Vincent Le Chevalier 
> <gal### [at] libertyallsurfspamfr> wrote:
>> Here's what I ended up with:
> [...snipped...]
> 
> The "right" way to do it, assuming C++:
> http://www.gotw.ca/gotw/057.htm
> 

Thanks for that!

-- 
Vincent

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> More exactly: It's a workaround for C's lack of lack of GOTO.

  Except that C does have goto.

-- 
                                                          - Warp

Post a reply to this message

Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> Of course, this being C, 'TRUE' could be a macro that expands to a function
>  that returns a value and thus the loop need not be infinite.

  Actually there are other ways for the loop to end. For instance, the
function being called could execute an exit() call.

  (Another less fancy way would be to return a null pointer from the
function, in which case the program will end with a segmentation fault.)

-- 
                                                          - Warp

Post a reply to this message

>> More exactly: It's a workaround for C's lack of lack of GOTO.
> 
>   Except that C does have goto.

Ooo, really?

In that case, I have *no clue* why they did it this way...

Oh, wait, maybe I do... Can you use GOTO to jump to a *pointer*? Or only 
a literal label?

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Warp wrote:

>   Actually there are other ways for the loop to end. For instance, the
> function being called could execute an exit() call.

I believe that is in fact what's meant to happen, yes.

>   (Another less fancy way would be to return a null pointer from the
> function, in which case the program will end with a segmentation fault.)

...or have count() perform any other illegal program-halting action.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> >> More exactly: It's a workaround for C's lack of lack of GOTO.
> > 
> >   Except that C does have goto.

> Ooo, really?

> In that case, I have *no clue* why they did it this way...

  Because "while(1)" is a common idiom, and avoids the ugly goto.

> Oh, wait, maybe I do... Can you use GOTO to jump to a *pointer*? Or only 
> a literal label?

  Jumping to a pointer is normally called "function call".

  Goto works only with labels.

-- 
                                                          - Warp

Post a reply to this message

>>>   Except that C does have goto.
> 
>> Ooo, really?
> 
>> In that case, I have *no clue* why they did it this way...
> 
>   Because "while(1)" is a common idiom, and avoids the ugly goto.
> 
>> Oh, wait, maybe I do... Can you use GOTO to jump to a *pointer*? Or only 
>> a literal label?
> 
>   Jumping to a pointer is normally called "function call".
> 
>   Goto works only with labels.

Yes, but jumping to a function pushes a return address onto the stack. 
And they specifically don't want to do that. (Because it would use an 
unbounded amount of stack.)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Yes, but jumping to a function pushes a return address onto the stack. 
> And they specifically don't want to do that. (Because it would use an 
> unbounded amount of stack.)

  Functions in C don't need to return anything.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Invisible <voi### [at] devnull> wrote:
>> More exactly: It's a workaround for C's lack of lack of GOTO.
> 
>   Except that C does have goto.

	I thought that's what "lack of lack of GOTO" meant.<G>

-- 
I almost had a psychic girlfriend, but she left me before I met her.


                     /\  /\               /\  /
                    /  \/  \ u e e n     /  \/  a w a z
                        >>>>>>mue### [at] nawazorg<<<<<<
                                    anl

Post a reply to this message

>> Yes, but jumping to a function pushes a return address onto the stack. 
>> And they specifically don't want to do that. (Because it would use an 
>> unbounded amount of stack.)
> 
>   Functions in C don't need to return anything.

The idea here is that we jump to one label, then jump to another, then 
jump to another, never returning to the "caller".

If we implement this using C functions that never return, an unbounded 
amount of stack gets eaten.

Hence, they arranged for each function to *return* the function it would 
like to jump to next, rather than actually jumping to it, and the loop I 
posted is apparently the magic incantation that implements the jumping.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Chris Cason wrote:

> In the real world, no programmer would ever do something
> that mean with a macro called TRUE. Right? :-)

There was an entry over at the Daily WTF in which someone posted code, 
written by another person, containing this:

#define TRUE 0
#define FALSE 1

I swear that I am not making this up.

Regards,
John

Post a reply to this message

Vincent Le Chevalier wrote:
> John VanSickle a écrit :
>> Invisible wrote:
>>> Can somebody interpret this for me?
>>>
>>>   while (TRUE) { cont = (*cont)(); }
>>>
>>> What on earth...?
>>
>> cont is a pointer to a function that is expected to return a pointer 
>> to a function.  The code here causes a series of functions to be 
>> called, each one specifying another function to be called afterwards 
>> by returning the address of the function to be called.
> 
> I was thinking the same, but I can't seem to find the right type 
> definition to make it work without casting to and from void*... Which is 
> apparently illegal 
> (http://www.parashift.com/c++-faq-lite/pointers-to-members.html#faq-33.8)

Casting back and forth from void* is considered exceptionally unwise in 
C++, but it's considered a great way of writing tighter code in C.

Regards,
John

Post a reply to this message

Warp wrote:
> Chris Cason <del### [at] deletethistoopovrayorg> wrote:
>> Of course, this being C, 'TRUE' could be a macro that expands to a function
>>  that returns a value and thus the loop need not be infinite.
> 
>   Actually there are other ways for the loop to end. For instance, the
> function being called could execute an exit() call.
> 
>   (Another less fancy way would be to return a null pointer from the
> function, in which case the program will end with a segmentation fault.)

Or return a pointer to the exit() function, which is the same as above.

Regards,
John

Post a reply to this message

John VanSickle <evi### [at] hotmailcom> wrote:
> Casting back and forth from void* is considered exceptionally unwise in 
> C++, but it's considered a great way of writing tighter code in C.

  In fact, for example casting method pointers to void* and back is
undefined behavior and in no way guaranteed to work. (And, in fact,
in many compilers method pointers are as large as two regular pointers,
and thus casting to void* would drop information.)

-- 
                                                          - Warp

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> The idea here is that we jump to one label, then jump to another, then
> jump to another, never returning to the "caller".
>
> If we implement this using C functions that never return, an unbounded
> amount of stack gets eaten.
>
> Hence, they arranged for each function to *return* the function it would
> like to jump to next, rather than actually jumping to it, and the loop I
> posted is apparently the magic incantation that implements the jumping.

Yes, indeed.

http://en.wikipedia.org/wiki/Tail_recursion#Implementation_methods

I take it that you were looking at the C output of GHC, right?  Haskell relies
on tail-recursion as much as any other functional language, as Scheme.  The
method it is implemented underneath is as a trampoline.

Post a reply to this message

John VanSickle wrote:

> There was an entry over at the Daily WTF in which someone posted code, 
> written by another person, containing this:
> 
> #define TRUE 0
> #define FALSE 1
> 
> I swear that I am not making this up.

I remember it well...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On 26-Jul-08 21:39, John VanSickle wrote:
> Chris Cason wrote:
> 
>> In the real world, no programmer would ever do something
>> that mean with a macro called TRUE. Right? :-)
> 
> There was an entry over at the Daily WTF in which someone posted code, 
> written by another person, containing this:
> 
> #define TRUE 0
> #define FALSE 1
> 
> I swear that I am not making this up.

Probably Unix convention?

http://en.wikipedia.org/wiki/True_(Unix)
http://en.wikipedia.org/wiki/False_(Unix)

Post a reply to this message

>> There was an entry over at the Daily WTF in which someone posted code, 
>> written by another person, containing this:
>>
>> #define TRUE 0
>> #define FALSE 1
>>
>> I swear that I am not making this up.
> 
> Probably Unix convention?

Ah yes - return code 0 = OK, any other code = failure.

What have we learned here? That using integers to represent Booleans is 
a Very Bad Thing. :-P

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> wrote:
> >> There was an entry over at the Daily WTF in which someone posted code, 
> >> written by another person, containing this:
> >>
> >> #define TRUE 0
> >> #define FALSE 1
> >>
> >> I swear that I am not making this up.
> > 
> > Probably Unix convention?

> Ah yes - return code 0 = OK, any other code = failure.

  C actually distinguishes between TRUE/FALSE and EXIT_SUCESS/EXIT_FAILURE.
They shouldn't be confused nor mixed.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> 
>   Because "while(1)" is a common idiom, and avoids the ugly goto.
> 

Either that or for(;;) { ... }

Post a reply to this message

>>   Because "while(1)" is a common idiom, and avoids the ugly goto.
> 
> Either that or for(;;) { ... }

...and to think people complain when a Haskell programmer writes

   fix ((1:) . scanl (+) 1)

or something... :-P

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Warp wrote:
>   (Another less fancy way would be to return a null pointer from the
> function, in which case the program will end with a segmentation fault.)

Well, maybe if you're lucky. :-) Otherwise, it just goes off happily 
executing whatever is at memory address zero (or whatever NULL maps to).

-- 
Darren New / San Diego, CA, USA (PST)
  Helpful housekeeping hints:
   Check your feather pillows for holes
    before putting them in the washing machine.

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> >   (Another less fancy way would be to return a null pointer from the
> > function, in which case the program will end with a segmentation fault.)

> Well, maybe if you're lucky. :-) Otherwise, it just goes off happily 
> executing whatever is at memory address zero (or whatever NULL maps to).

  I'm pretty sure POSIX or some other type of standard states that jumping
to the null pointer will always cause a segmentation fault.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Warp wrote:
>>>   (Another less fancy way would be to return a null pointer from the
>>> function, in which case the program will end with a segmentation fault.)
> 
>> Well, maybe if you're lucky. :-) Otherwise, it just goes off happily 
>> executing whatever is at memory address zero (or whatever NULL maps to).
> 
>   I'm pretty sure POSIX or some other type of standard states that jumping
> to the null pointer will always cause a segmentation fault.

But not the C standard. Try it on MS-DOS, Win 3.1, AmigaDOS, a credit 
card terminal, a cell phone, etc. :-)  Basically, you're saying you 
can't have a POSIX-compliant system without memory mapping, methinks. 
But C is used in particular because of its primitiveness and lack of 
reliance on a particular complex bit of hardware.

"The operating system is there to provide the facilities the language 
designer left out."

-- 
Darren New / San Diego, CA, USA (PST)
  Helpful housekeeping hints:
   Check your feather pillows for holes
    before putting them in the washing machine.

Post a reply to this message