On 10/15/23 3:51 PM, Pavel wrote:
> Anton Shepelev wrote:
>> candycanearter07 to Anton Shepelev:
>>
>>>> And although C allows the definition of self-referential
>>>> structs, it does [not] allow the declaration of self-
>>>> referencial functions.
>>>
>>> What if you typedef'd the function pointer?
>>
>> That's what I did:
>>
>>     typedef void   (*fp   )( void );
>>     typedef stm_fp (*func )( struct my_struct * s, int i );
>>
>> As you see, the `func' still must return something other
>> than func...
>>
>>> Also, you could probably get away with it by just setting
>>> it to a void pointer and casting the return value to the
>>> function pointer.
>>
>> Yes, to a void /function/ pointer, because void* is
>> incompatible with void(*)(void).  And then it is not a
>> truely recursive declaration, and requires additional work
>> to invoke.
> ...
>
> The below seems to work in gcc, unsure if this is standard-compliant but
> does not require extra work to invoke. If it is, I understand that the
> fptr type is not that of pointer to f, but your question does not
> qualify whether the function should return the value of a pointer to
> itself or a pointer of type of itself or both. If the former, the answer
> seems to be "yes" because the second call by pointer seems to work, no?
>
>
> typedef void* (*vfptr_t)();
>
> vfptr_t f(int n)
> {
>   printf("I am f n=%d\n", n);
>   return (vfptr_t)&f;
> }
>
> int
> main(int argc, char* argv[])
> {
>   vfptr_t fptr = f(5);
>   fptr(6);
>   return 0;
> }

No, it doesn't meet the strict definition of the challenge, as if it
did, then the following would work:

int
main()
{ vfptr_t fptr1 = f(5);
vfptr_t fptr2 = fptr1(6);
return 0;
}

as the pointer needs to act just like the function.

It seems that the best that can be done is to have the function actually
return a pointer to some function type, and then cast that to another
type that represents a function that returns a pointer the that function
type.

The issue is that to make it return the right type without needing a
cast, forces an infinite level of indirection in the type, while with
the cast, in adding one level, makes things work.

The problem is that in calling, we are effectively removing a level of
indirection from the definition and the only sort of number that can be
reduced by 1 and still be the same is an infinite number.

On 10/15/23 15:51, Pavel wrote:
> Anton Shepelev wrote:
>> candycanearter07 to Anton Shepelev:
>>
>>>> And although C allows the definition of self-referential
>>>> structs, it does [not] allow the declaration of self-
>>>> referencial functions.

Just for the sake of those who might not remember (I'm not suggesting
that you are one of them), this discussion is about C, even though
cross-posted to comp.lang.c++. Citations below are from the C standard.

....
> The below seems to work in gcc, unsure if this is standard-compliant but
> does not require extra work to invoke. If it is, I understand that the
> fptr type is not that of pointer to f, but your question does not
> qualify whether the function should return the value of a pointer to
> itself or a pointer of type of itself or both. If the former, the answer
> seems to be "yes" because the second call by pointer seems to work, no?
>
>
> typedef void* (*vfptr_t)();
>
> vfptr_t f(int n)
> {
> printf("I am f n=%d\n", n);
> return (vfptr_t)&f;
> }
>
> int
> main(int argc, char* argv[])
> {
> vfptr_t fptr = f(5);
> fptr(6);
> return 0;
> }

"If the function is defined with a type that is not compatible with the
type (of the expression) pointed to by the expression that denotes the
called function, the behavior is undefined." (6.5.2.2p9)

The type of f() is "vfptr_t f(int)". The type pointed at by fptr is
"void*()".

"For two function types to be compatible, both shall specify compatible
return types." (6.7.5.3p15)

void* and vfptr_t are not compatible types, so the type of f() is not
compatible with the type pointed at by fptr. The behavior is undefined,
even though your code makes no use of the value returned by that function.

James Kuyper wrote:
> On 10/15/23 15:51, Pavel wrote:
>> Anton Shepelev wrote:
>>> candycanearter07 to Anton Shepelev:
>>>
>>>>> And although C allows the definition of self-referential
>>>>> structs, it does [not] allow the declaration of self-
>>>>> referencial functions.
>
> Just for the sake of those who might not remember (I'm not suggesting
> that you are one of them), this discussion is about C, even though
> cross-posted to comp.lang.c++. Citations below are from the C standard.
>
> ...
>> The below seems to work in gcc, unsure if this is standard-compliant but
>> does not require extra work to invoke. If it is, I understand that the
>> fptr type is not that of pointer to f, but your question does not
>> qualify whether the function should return the value of a pointer to
>> itself or a pointer of type of itself or both. If the former, the answer
>> seems to be "yes" because the second call by pointer seems to work, no?
>>
>>
>> typedef void* (*vfptr_t)();
>>
>> vfptr_t f(int n)
>> {
>> printf("I am f n=%d\n", n);
>> return (vfptr_t)&f;
>> }
>>
>> int
>> main(int argc, char* argv[])
>> {
>> vfptr_t fptr = f(5);
>> fptr(6);
>> return 0;
>> }
>
> "If the function is defined with a type that is not compatible with the
> type (of the expression) pointed to by the expression that denotes the
> called function, the behavior is undefined." (6.5.2.2p9)
>
> The type of f() is "vfptr_t f(int)". The type pointed at by fptr is
> "void*()".
yes, I noticed. this works as well (with same parameter types):

/* cut here -----------------*/
#include <stdio.h>

typedef void* (*vfptr_t)(int);

vfptr_t f(int n)
{ printf("I am f n=%d\n", n);
return (vfptr_t)f;
}

int
main(int argc, char* argv[])
{ (void)argc;
(void)argv;
vfptr_t fptr = f(5);
fptr(6);
return 0;
} /* cut here -----------------*/

>
> "For two function types to be compatible, both shall specify compatible
> return types." (6.7.5.3p15)
I see, thanks.
>
> void* and vfptr_t are not compatible types, so the type of f() is not
> compatible with the type pointed at by fptr. The behavior is undefined,
> even though your code makes no use of the value returned by that function.
Doesn't it use the returned value by assigning it to fptr and then
calling f thru it?

On 10/16/23 10:01 PM, Pavel wrote:
> James Kuyper wrote:
>> On 10/15/23 15:51, Pavel wrote:
>>> Anton Shepelev wrote:
>>>> candycanearter07 to Anton Shepelev:
>>>>
>>>>>> And although C allows the definition of self-referential
>>>>>> structs, it does [not] allow the declaration of self-
>>>>>> referencial functions.
>>
>> Just for the sake of those who might not remember (I'm not suggesting
>> that you are one of them), this discussion is about C, even though
>> cross-posted to comp.lang.c++. Citations below are from the C standard.
>>
>> ...
>>> The below seems to work in gcc, unsure if this is standard-compliant but
>>> does not require extra work to invoke. If it is, I understand that the
>>> fptr type is not that of pointer to f, but your question does not
>>> qualify whether the function should return the value of a pointer to
>>> itself or a pointer of type of itself or both. If the former, the answer
>>> seems to be "yes" because the second call by pointer seems to work, no?
>>>
>>>
>>> typedef void* (*vfptr_t)();
>>>
>>> vfptr_t f(int n)
>>> {
>>>     printf("I am f n=%d\n", n);
>>>     return (vfptr_t)&f;
>>> }
>>>
>>> int
>>> main(int argc, char* argv[])
>>> {
>>>     vfptr_t fptr = f(5);
>>>     fptr(6);
>>>     return 0;
>>> }
>>
>> "If the function is defined with a type that is not compatible with the
>> type (of the expression) pointed to by the expression that denotes the
>> called function, the behavior is undefined." (6.5.2.2p9)
>>
>> The type of f() is "vfptr_t f(int)". The type pointed at by fptr is
>> "void*()".
> yes, I noticed. this works as well (with same parameter types):
>
> /* cut here -----------------*/
> #include <stdio.h>
>
> typedef void* (*vfptr_t)(int);
>
> vfptr_t f(int n)
> {
>   printf("I am f n=%d\n", n);
>   return (vfptr_t)f;
> }
>
> int
> main(int argc, char* argv[])
> {
>   (void)argc;
>   (void)argv;
>   vfptr_t fptr = f(5);
>   fptr(6);
>   return 0;
> }
> /* cut here -----------------*/
>
>
>>
>> "For two function types to be compatible, both shall specify compatible
>> return types." (6.7.5.3p15)
> I see, thanks.
>>
>> void* and vfptr_t are not compatible types, so the type of f() is not
>> compatible with the type pointed at by fptr. The behavior is undefined,
>> even though your code makes no use of the value returned by that
>> function.
> Doesn't it use the returned value by assigning it to fptr and then
> calling f thru it?
>
>

The issue is that the call to fptr(6) thinks it is calling a function
that return a void*, but it is actually calling a function that returns
a pointer to a function that returns a void*, those aren't the same type
of function, so you get undefined behavior.

And that is why you needed the cast in the function.

It is also why if you made the second call into:

vfptr_t fptr2 = fptr(6);

you would get an error, as the function type of fptr doesn't return
something compatible with vfptr_t. That is using the return value of the
call through the returned function pointer, as that is where the error is.

On 10/17/23 07:05, Anton Shepelev wrote:
> James Kuyper:
>
>> One of the most common and most dangerous things that can
>> happen when the behavior of code is undefined, is that it
>> happens to behave in precisely the fashion you
>> unjustifiably expected it to behave, leaving you unaware
>> of the [Ant: a?] flaw in your program.

You're right - "a" works better; we don't know that it's the only flaw.

"Antwrong" Shepelev <anton.txt@g{oogle}mail.com> writes:
> Lynn McGuire:
>
>> ChattyG takes a college freshman C/C++ programming exam
>> https://www.theregister.com/2023/10/03/chatgpt_code_college
>
> By the way, the actual paper does not mention anything
> called ChattyG. The journalist must have used the term
> erroneously.

Incorrect. For reasons that should now be obvious.

Phil
--
We are no longer hunters and nomads. No longer awed and frightened, as we have
gained some understanding of the world in which we live. As such, we can cast
aside childish remnants from the dawn of our civilization.
-- NotSanguine on SoylentNews, after Eugen Weber in /The Western Tradition/

Phil Carmody to Anton Shepelev:

> > Anton Shepelev:
> >
> > > ChattyG takes a college freshman C/C++ programming exam
> > > https://www.theregister.com/2023/10/03/chatgpt_code_college
> >
> > By the way, the actual paper does not mention anything
> > called ChattyG. The journalist must have used the term
> > erroneously.
>
> Incorrect. For reasons that should now be obvious.

No, not to me.

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

Anton Shepelev <anton.txt@g{oogle}mail.com> writes:
> Phil Carmody to Anton Shepelev:
>> > Anton Shepelev:
>> >
>> > > ChattyG takes a college freshman C/C++ programming exam
>> > > https://www.theregister.com/2023/10/03/chatgpt_code_college
>> >
>> > By the way, the actual paper does not mention anything
>> > called ChattyG. The journalist must have used the term
>> > erroneously.
>>
>> Incorrect. For reasons that should now be obvious.
>
> No, not to me.

Yet you felt the need to edit my post when replying to it.

No entity gets to enforce how other people refer to them.

Phil
--
We are no longer hunters and nomads. No longer awed and frightened, as we have
gained some understanding of the world in which we live. As such, we can cast
aside childish remnants from the dawn of our civilization.
-- NotSanguine on SoylentNews, after Eugen Weber in /The Western Tradition/