“ChattyG takes a college freshman C/C++ programming exam”
https://www.theregister.com/2023/10/03/chatgpt_code_college/

“ChatGPT was put to the test via a series of humdrum freshman C/C++
programming tasks and it passed – though not with honors.”

“According to a Croatian research team, while first-year students can
struggle with some of the assignments, the results [PDF] showed ChatGPT
hitting proficiency targets that ranged between average and that of
experienced programmers. And naturally, as with all college exams,
outcomes can be determined by how questions are worded.”

Lynn

On 10/5/2023 3:40 PM, Lynn McGuire wrote:
> “ChattyG takes a college freshman C/C++ programming exam”
>    https://www.theregister.com/2023/10/03/chatgpt_code_college/
>
> “ChatGPT was put to the test via a series of humdrum freshman C/C++
> programming tasks and it passed – though not with honors.”
>
> “According to a Croatian research team, while first-year students can
> struggle with some of the assignments, the results [PDF] showed ChatGPT
> hitting proficiency targets that ranged between average and that of
> experienced programmers. And naturally, as with all college exams,
> outcomes can be determined by how questions are worded.”

If we keep teaching it, it should get better and better... :^o

Am 06.10.23 um 00:40 schrieb Lynn McGuire:
> “ChattyG takes a college freshman C/C++ programming exam”
>    https://www.theregister.com/2023/10/03/chatgpt_code_college/
>
> “ChatGPT was put to the test via a series of humdrum freshman C/C++
> programming tasks and it passed – though not with honors.”

This is already outdated. I've read the paper and they used the free
version, aka GPT-3.5. They should repeat the same tests with at least
GPT-4. There is a vast improvement especially in programming skill from
3.5 to 4.

In addition, there are open source models available which you can run on
your own computer [1], some of them are specifically finetuned towards
coding - e.g. WizardCoder [2]. The version finetuned to Python
specifically is claimed to surpass GPT-4 in some benchmarks. It can be
downloaded in quantized form, ready to run even CPU-only on a machine
with sufficient RAM [1,3]

[1] https://github.com/ggerganov/llama.cpp
[2] https://github.com/nlpxucan/WizardLM/
[3] https://huggingface.co/TheBloke/WizardCoder-Python-34B-V1.0-GGUF

Christian

On 10/5/2023 10:36 PM, Christian Gollwitzer wrote:
> Am 06.10.23 um 00:40 schrieb Lynn McGuire:
>> “ChattyG takes a college freshman C/C++ programming exam”
>>     https://www.theregister.com/2023/10/03/chatgpt_code_college/
>>
>> “ChatGPT was put to the test via a series of humdrum freshman C/C++
>> programming tasks and it passed – though not with honors.”
>
> This is already outdated. I've read the paper and they used the free
> version, aka GPT-3.5. They should repeat the same tests with at least
> GPT-4. There is a vast improvement especially in programming skill from
> 3.5 to 4.
>
> In addition, there are open source models available which you can run on
> your own computer [1], some of them are specifically finetuned towards
> coding - e.g. WizardCoder [2]. The version finetuned to Python
> specifically is claimed to surpass GPT-4 in some benchmarks. It can be
> downloaded in quantized form, ready to run even CPU-only on a machine
> with sufficient RAM [1,3]
>
> [1] https://github.com/ggerganov/llama.cpp
> [2] https://github.com/nlpxucan/WizardLM/
> [3] https://huggingface.co/TheBloke/WizardCoder-Python-34B-V1.0-GGUF

Thanks for the links. :^)

Lynn McGuire:

> ChattyG takes a college freshman C/C++ programming exam
> https://www.theregister.com/2023/10/03/chatgpt_code_college/

For me, it failed the very trivia:

AS: Can a C function return a pointer to itself?

CG: Yes, a C function can return a pointer to itself. This
is known as a recursive function, where a function calls
itself repeatedly until a certain condition is met. In
this case, the function would return a pointer to the
function itself to enable the recursive call.

I asked that question here:

<https://app.chatty-g.com/>
--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

Anton Shepelev ha scritto:
> Lynn McGuire:
>
>> ChattyG takes a college freshman C/C++ programming exam
>> https://www.theregister.com/2023/10/03/chatgpt_code_college/
>
> For me, it failed the very trivia:
>
> AS: Can a C function return a pointer to itself?
>
> CG: Yes, a C function can return a pointer to itself. This
> is known as a recursive function, where a function calls
> itself repeatedly until a certain condition is met. In
> this case, the function would return a pointer to the
> function itself to enable the recursive call.
>
> I asked that question here:
>
> <https://app.chatty-g.com/>
>

The explanation is certainly wrong but it is true that it is possible:

#include <stdio.h>

typedef void (* fptr)(int) ;

fptr foo(int n)
{ printf("Call n. %d\n", n);

return (fptr)foo;
}

int main()
{ fptr p = foo(1);

p(2);

return 0;
}

Out:

Call n. 1
Call n. 2

On 10/8/23 03:42, jak wrote:
> Anton Shepelev ha scritto:
>> Lynn McGuire:
>>
>>> ChattyG takes a college freshman C/C++ programming exam
>>> https://www.theregister.com/2023/10/03/chatgpt_code_college/
>>
>> For me, it failed the very trivia:
>>
>> AS: Can a C function return a pointer to itself?
>>
>> CG: Yes, a C function can return a pointer to itself. This
>> is known as a recursive function, where a function calls
>> itself repeatedly until a certain condition is met. In
>> this case, the function would return a pointer to the
>> function itself to enable the recursive call.
>>
>> I asked that question here:
>>
>> <https://app.chatty-g.com/>
>>
>
> The explanation is certainly wrong but it is true that it is possible:
>
> #include <stdio.h>
>
> typedef void (* fptr)(int) ;
>
> fptr foo(int n)
> {
> printf("Call n. %d\n", n);
>
> return (fptr)foo;
> }
>
> int main()
> {
> fptr p = foo(1);
>
> p(2);

The return type of *p is void; the return type of foo is fptr.

"Calling a function through an expression whose function type is
different from the function type of the called
function’s definition results in undefined behavior." (7.6.1.2p6)

jak to Anton Shepelev:

> > AS: Can a C function return a pointer to itself?
> > CG: Yes, a C function can return a pointer to itself.
>
> The explanation is certainly wrong but it is true that it
> is possible:

I disagree. A function returns the value of its declared
return type. And although C allows the definition of self-
referential structs, it does allow the declaration of self-
referencial functions.

> #include <stdio.h>
>
> typedef void (* fptr)(int) ;
>
> fptr foo(int n)
> {
> printf("Call n. %d\n", n);
> return (fptr)foo;
> }
>
> int main()
> {
> fptr p = foo(1);
> p(2);
> return 0;
> }
>
> Out:
>
> Call n. 1
> Call n. 2

You are converting void to function pointer fptr. This is
not supported in C. You might have taken advantage of
void*, which is silently convertible to any pointer, but
then again it does not work with function pointer, and C has
not analog of void* for functions pointers, so an explicit
conversion is seem inevitable.

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

Anton Shepelev:

> And although C allows the definition of self-referential
> structs, it does allow the declaration of self-referencial
> functions.

does /not/ allow.

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

On 10/8/23 04:55, Anton Shepelev wrote:
> I disagree. A function returns the value of its declared
> return type. And although C allows the definition of self-
> referential structs, it does allow the declaration of self-
> referencial functions.

What if you typedef'd the function pointer?

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.
--
user <candycane> is generated from /dev/urandom

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. And the following does not compile, of course:

typedef func (*func )( struct my_struct * s, int i );

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

Anton Shepelev <anton.txt@gmail.moc> writes:

> jak to Anton Shepelev:
>
>> > AS: Can a C function return a pointer to itself?
>> > CG: Yes, a C function can return a pointer to itself.
>>
>> The explanation is certainly wrong but it is true that it
>> is possible:
>
> I disagree. A function returns the value of its declared
> return type. And although C allows the definition of self-
> referential structs, it does [not] allow the declaration of self-
> referencial functions.

C does not have any way to express the /type/ of a function that returns
a pointer to itself. But self-referential functions (as most people
would use the term) are commonplace, many of them having very dull and
ordinary types!

>> #include <stdio.h>
>>
>> typedef void (* fptr)(int) ;
>>
>> fptr foo(int n)
>> {
>> printf("Call n. %d\n", n);
>> return (fptr)foo;
>> }
>>
>> int main()
>> {
>> fptr p = foo(1);
>> p(2);
>> return 0;
>> }

> You are converting void to function pointer fptr. This is not
> supported in C.

Not in the fragment shown. The conversion is from one
pointer-to-function type (void (*(*)(int))(int)) to another (void
(*)(int)) and that's allowed.

The trouble is that foo and foo(1) have different pointer-to-function
types. If C could express the right type, one could write

foo(1)(2)(3)(4);

but is it stands we can only write

foo(1)(2);

before the types go wrong. A third chained call would try to "call" a
void result.

> You might have taken advantage of
> void*, which is silently convertible to any pointer, but
> then again it does not work with function pointer, and C has
> not analog of void* for functions pointers, so an explicit
> conversion is seem inevitable.

I think it would be reasonable to say that a function /can/ return a
pointer to itself. It's just that the type will be wrong. After all,
we are happy to say that (void *)&some_int_var is a pointer to that int
object even though the type is wrong. To use that pointer to get at the
int object, a conversion is required. Similarly, to use the pointer
returned by a function like foo, a conversion is required. I would do
it like this:

#include <stdio.h>

typedef void (*generic_function_ptr)(void);
typedef generic_function_ptr (*fintp)(int);

generic_function_ptr foo(int n)
{
printf("Call n. %d\n", n);
return foo;
}

int main(void)
{
((fintp)((fintp)foo(1))(2))(3);
}

--
Ben.

On 10/8/23 03:42, jak wrote:
> Anton Shepelev ha scritto:
....
>> For me, it failed the very trivia:
>>
>> AS: Can a C function return a pointer to itself?
>>
>> CG: Yes, a C function can return a pointer to itself. This
>> is known as a recursive function, where a function calls
>> itself repeatedly until a certain condition is met. In
>> this case, the function would return a pointer to the
>> function itself to enable the recursive call.
>>
>> I asked that question here:
>>
>> <https://app.chatty-g.com/>
>>
>
> The explanation is certainly wrong but it is true that it is possible:
>
> #include <stdio.h>
>
> typedef void (* fptr)(int) ;
>
> fptr foo(int n)
> {
> printf("Call n. %d\n", n);
>
> return (fptr)foo;
> }
>
> int main()
> {
> fptr p = foo(1);
>
> p(2);

The return type of *p is void; the return type of foo is fptr.

Sorry - when I first wrote up a reply to this, I provided an answer that
cited the C standard. Then just before I posted it, I notices that I was
posting to comp.lang.c++, so I quickly "corrected" it to cite the C++
standard. And just now I noticed that the question was explicitly about
C. So here's the original citations:

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

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

On 10/8/23 05:55, Anton Shepelev wrote:
> jak to Anton Shepelev:
>
>>> AS: Can a C function return a pointer to itself?
>>> CG: Yes, a C function can return a pointer to itself.
>>
>> The explanation is certainly wrong but it is true that it
>> is possible:
>
> I disagree. A function returns the value of its declared
> return type. And although C allows the definition of self-
> referential structs, it does allow the declaration of self-
> referencial functions.
>
>> #include <stdio.h>
>>
>> typedef void (* fptr)(int) ;
>>
>> fptr foo(int n)
>> {
>> printf("Call n. %d\n", n);
>> return (fptr)foo;

The line above converts "fptr(*)(int)" to "void(*)(int)'.

>> }
>>
>> int main()
>> {
>> fptr p = foo(1);>> p(2);
>> return 0;
>> }
>>
>> Out:
>>
>> Call n. 1
>> Call n. 2
>
> You are converting void to function pointer fptr. ...

I see no such conversion in the above code. Could you identify where it
occurs?

> ... This is
> not supported in C. You might have taken advantage of
> void*, which is silently convertible to any pointer, but
> then again it does not work with function pointer, and C has
> not analog of void* for functions pointers,so an explicit
> conversion is seem inevitable.

That's true - but the only conversion I can find in the above code is in
fact explicit, not implicit.
It's the function call that has undefined behavior, due to the code's
failure to convert the pointer back to it's original type. There's
nothing wrong with the conversion that is actually present.

Anton Shepelev wrote:

> You are converting void to function pointer fptr. This is not supported
> in C. You might have taken advantage of void*, which is silently
> convertible to any pointer, but then again it does not work with
> function pointer, and C has not analog of void* for functions pointers,
> so an explicit conversion is seem inevitable.

It mayn't be supported in standard C, but it's a common extension—in fact,
POSIX _requires_ it in order for the dlsym subroutine to work.

--
Blue-Maned_Hawk│shortens to
Hawk│/
blu.mɛin.dÊ°ak/
│he/him/his/himself/Mr.
bluemanedhawk.github.io
Y'know, the one with the thing!

Blue-Maned_Hawk:
[Unicode em-dash replaced with --]
> [functions returning pointers to themselves]
> It mayn't be supported in standard C, but it's a common
> extension--in fact, POSIX _requires_ it in order for the
> dlsym subroutine to work.

How so, when casing the return value (from a different
function pointer) does not solve the problem?

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

James Kuyper to Anton Shepelev:

> > You are converting void to function pointer fptr. ...
>
> I see no such conversion in the above code. Could you
> identify where it occurs?

You are correct. I overlooked that the OP's ignores the
return value, and therefore need not convert it to anything
to make it useful.

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

On 10/8/2023 4:22 AM, candycanearter07 wrote:
> On 10/8/23 04:55, Anton Shepelev wrote:
>> I disagree.  A function returns the value of its declared
>> return type.  And although C allows the definition of self-
>> referential structs, it does allow the declaration of self-
>> referencial functions.
>
> What if you typedef'd the function pointer?
>
> 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.

Not sure if that's allowed. A function pointer cast to a void pointer,
which in turn is cast back to a function pointer is undefined? What am I
forgetting here?

Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> writes:
> Anton Shepelev wrote:
>> You are converting void to function pointer fptr. This is not supported
>> in C. You might have taken advantage of void*, which is silently
>> convertible to any pointer, but then again it does not work with
>> function pointer, and C has not analog of void* for functions pointers,
>> so an explicit conversion is seem inevitable.
>
> It mayn't be supported in standard C, but it's a common extension—in fact,
> POSIX _requires_ it in order for the dlsym subroutine to work.

The POSIX requirement is limited to values returned by dlsym().

https://pubs.opengroup.org/onlinepubs/9699919799/functions/dlsym.html

> The return value from dlsym(), cast to a pointer to the type of the
> named symbol, can be used to call (in the case of a function) or access
> the contents of (in the case of a data object) the named symbol.

An implementation could satisfy that requirement without supporting
void* to function pointer conversions in general.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

On 10/8/23 3:31 PM, Chris M. Thomasson wrote:
> On 10/8/2023 4:22 AM, candycanearter07 wrote:
>> On 10/8/23 04:55, Anton Shepelev wrote:
>>> I disagree.  A function returns the value of its declared
>>> return type.  And although C allows the definition of self-
>>> referential structs, it does allow the declaration of self-
>>> referencial functions.
>>
>> What if you typedef'd the function pointer?
>>
>> 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.
>
> Not sure if that's allowed. A function pointer cast to a void pointer,
> which in turn is cast back to a function pointer is undefined? What am I
> forgetting here?

While not specifically called out as undefined behavior, it also isn't
ever said to be allowed.

It will work on the most common processors currently, but I have an
active product using a processor where it will definitely NOT work, as
function pointers are bigger than object pointers.

The Posix standard sort of requires that it works, but only for a
certain set of function pointers, so you can do a work around for
machines that don't actually support it.

One way to acheive the results is define the return type as a pointer to
some defined type of function, and you cast the return value to a
pointer to a function that returns that type of function, and in the
function cast the pointer to itself to that type of function.

i.e.

typedef void (*fret)(); // fret is a simplifed type we can return
typedef fret (*pf)(); // pf is the actual type of the function.

fret func() {
return (fret) func;
}

int main() {

pf p = (pf)func(); // Call the function and cast the return value
pf p2 = (pf)p(); // call the same function from the pointer
}

Note, the standard specifically says we can cast any function pointer
type to another function pointer type and back and get a usable pointer.

(untested code, but should be at least close)

On 10/8/23 18:31, Keith Thompson wrote:
> Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> writes:
>> Anton Shepelev wrote:
>>> You are converting void to function pointer fptr. This is not supported
>>> in C. You might have taken advantage of void*, which is silently
>>> convertible to any pointer, but then again it does not work with
>>> function pointer, and C has not analog of void* for functions pointers,
>>> so an explicit conversion is seem inevitable.
>>
>> It mayn't be supported in standard C, but it's a common extension—in fact,
>> POSIX _requires_ it in order for the dlsym subroutine to work.
>
> The POSIX requirement is limited to values returned by dlsym().
>
> https://pubs.opengroup.org/onlinepubs/9699919799/functions/dlsym.html

I've heard that before, and it might be true - but I don't see words to
that effect on that page. It says:

"Note that conversion from a void * pointer to a function pointer as in:

fptr = (int (*)(int))dlsym(handle, "my_function");

is not defined by the ISO C standard. This standard requires this
conversion to work correctly on conforming implementations."

As I read it, that requires that the conversion work in general - it
says nothing about it working only for values returned by dlsym.

On 10/8/23 21:17, Richard Damon wrote:
> On 10/8/23 3:31 PM, Chris M. Thomasson wrote:
....
>> Not sure if that's allowed. A function pointer cast to a void
>> pointer, which in turn is cast back to a function pointer is
>> undefined? What am I forgetting here?
>
> While not specifically called out as undefined behavior, it also isn't
> ever said to be allowed.

Precisely - it is undefined "... by the omission of any explicit
definition of behavior." (4p2

On 10/8/23 13:05, Anton Shepelev wrote:
> Blue-Maned_Hawk:
> [Unicode em-dash replaced with --]
>> [functions returning pointers to themselves]
>> It mayn't be supported in standard C, but it's a common
>> extension--in fact, POSIX _requires_ it in order for the
>> dlsym subroutine to work.
>
> How so, when casing the return value (from a different
> function pointer) does not solve the problem?

The problem is behavior that is not defined by the C standard. POSIX
solves the problem by defining the behavior:

"Note that conversion from a void * pointer to a function pointer as in:

fptr = (int (*)(int))dlsym(handle, "my_function");

is not defined by the ISO C standard. This standard requires this
conversion to work correctly on conforming implementations."

"This standard" refers to the POSIX standard, not the C standard.

Anton Shepelev wrote:

> Blue-Maned_Hawk:
> [Unicode em-dash replaced with --]

Why?

>> [functions returning pointers to themselves]
>> It mayn't be supported in standard C, but it's a common extension--in
>> fact, POSIX _requires_ it in order for the dlsym subroutine to work.
>
> How so, when casing the return value (from a different function pointer)
> does not solve the problem?

I was not referring to functions returning pointers to themselves in the
quoted part of my message. I was referring to void * being castable to a
function pointer.

--
Blue-Maned_Hawk│shortens to
Hawk│/
blu.mɛin.dÊ°ak/
│he/him/his/himself/Mr.
bluemanedhawk.github.io
Variably constant!

Blue-Maned_Hawk to Anton Shepelev:

> > Blue-Maned_Hawk:
> > [Unicode em-dash replaced with --]
>
> Why?

Oh, it just doesn't go with Usenet, stylistically and
aesthetically. English plain-text is must like
code -- 7-bit-clean. And like code (e.g. for Troff or
LaTeX), there are convensions for dashes, /italic/ text,
<URLs>, &c. Your signature is a mess of Unicode
characters -- terrible :-!

> > > It mayn't be supported in standard C, but it's a
> > > common extension--in fact, POSIX _requires_ it in
> > > order for the dlsym subroutine to work.
> >
> > How so, when casing the return value (from a different
> > function pointer) does not solve the problem?
>
> I was not referring to functions returning pointers to
> themselves in the quoted part of my message. I was
> referring to void * being castable to a function pointer.

Yes, and I asked why the authors of that API decided not to
use the casing that is guarranteed to work, preferring the
dubious casing of void* to function pointers. If /I/ were
the designer (should you be afraid?), I should make it two
functions:

void * dlsym_o(void *restrict handle, const char *restrict name);
void(*)(void) dlsym_f(void *restrict handle, const char *restrict name);

because the caller usually knows what he seeks. If he
doesn't, let it be a single function with a compund return
type. I am not sure what a good way to do it would be,
however, because, having to declare a struct, (with possibly
an union inside) and an enum just for this function may be
bloat, yet:--

enum dlsym_type {dsOBJ, dsFUN, dsNA}; /* the 3rd member optional */

struct dlsym_info
{ char is_found; /* flag, optional */
enum dlsym_type type ; /* optional */
void * obj_ptr ; /* NULL if not found */
void(*)(void) fun_ptr ; /* NULL if not found */
}

`optional' above means the element may be omitted from the
interface. For example, dsNA and .is_found are mutually
exclusive, and both the flag and the enum may be done away
with by requiring that the caller use whichever pointer is
not NULL, and consider the symbol not found if both are
NULL.

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