“ChattyG takes a college freshman C/C++ programming exam”

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

“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

[Chris M. Thomasson]

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

[Christian Gollwitzer]

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

[Chris M. Thomasson]

Thanks for the links. :^)

[Anton Shepelev]

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

[jak]

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

[James Kuyper]

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)

[Anton Shepelev]

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.

[Anton Shepelev]

Anton Shepelev:

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

does /not/ allow.

[candycanearter07]

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

[Anton Shepelev]

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 );

[Ben Bacarisse]

Anton Shepelev <anto...@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.

[James Kuyper]

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

[James Kuyper]

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.

[Blue-Maned_Hawk]

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!

[Anton Shepelev]

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?

[Anton Shepelev]

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.

[Chris M. Thomasson]

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?

[Keith Thompson]

Blue-Maned_Hawk <bluema...@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.T...@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

[Richard Damon]

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)

[James Kuyper]

On 10/8/23 18:31, Keith Thompson wrote:
> Blue-Maned_Hawk <bluema...@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.

[James Kuyper]

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

[James Kuyper]

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.

[Blue-Maned_Hawk]

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!

[Anton Shepelev]

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.

[Anton Shepelev]

Keith Thompson to Blue-Maned_Hawk:

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

Sounds a like an unnecessary special case and a loophole,
when a standard solution exists:

Message-ID: <20231009230305.adfd...@gmail.moc>
Archived : http://al.howardknight.net/?ID=169688196000

[Scott Lurndal]

Anton Shepelev <anto...@gmail.moc> writes:
>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.

Because all POSIX systems of the day had identically
sized function and object pointers, and the committee possibly
did not believe that there would ever be a future architecture
for which POSIX would be useful that had a distinction
between object and function pointers and they had little
interest in obsoleting existing code.

dlsym showed up about 1990 in SVR4, coming from SunOS IIRC.

[Chris M. Thomasson]

That about sums it all up. POSIX does not equal the C/C++ standards. If
a system and one of its C compilers claims support for POSIX, well so be it.

[Scott Lurndal]

If you're using dlsym in your application, you are unlikely to be using
a non-POSIX system in the first place.

[Anton Shepelev]

Scott Lurndal to Anton Shepelev:

> > 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.
>
> Because all POSIX systems of the day had identically sized
> function and object pointers, and the committee possibly
> did not believe that there would ever be a future
> architecture for which POSIX would be useful that had a
> distinction between object and function pointers

Sounds like a instance myopic thinking. Compliance with the
Standard is always the safest road into the future. ("Write
it down in your notebooks, gentlemen!"[1])

> and they had little interest in obsoleting existing code.
>
> dlsym showed up about 1990 in SVR4, coming from SunOS
> IIRC.

What was there to obsolete in 1990, or did you mean ever
since?
____________________
1. /One-storied America/

[Ben Bacarisse]

Anton Shepelev <anto...@gmail.moc> writes:

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

What is aesthetically wrong about using a bullet-point marker? What
is stylistically wrong about writing accented characters?

> English plain-text is much like
> code -- 7-bit-clean.

That's circular. By "plain-text" you mean 7-bit clean. Texts written
in English have, traditionally, used all sort of typographical marks,
and it has always been considered goof style to write correctly.
Phonetic script should be rendered correctly. Foreign words should be
rendered correctly.

What many people think of a "plain" English text is just what we've been
forced to write by clunky technology; first typewriters and then
computers. We should more on. There was a time when people would moan
if I sent a file with lower case letters in it because it could not be
rendered on a CDC mainframe. Come on, it's the 21st century.

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

BMH has posted a bad signature. It's not UTF-8 encoded Unicode at all,
despite what the header says. It is what's called mojibake.

In fact, properly rendered, his sig just contains a few phonetic letters
and, oddly, some "BOX DRAWINGS LIGHT VERTICAL" lines for which I would
have used | (despite what I wrote above).

Of course the fact that he did not post it correctly could be seen as
undermining my case, but I take as a further call to action: come on
BMH, buck up and get it right!

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

Almost certainly a case that the designers knew the system involved and
were solving an immediate problem for one particular OS on a limited
class of machines (SunOS, I think). They never thought that people
would still be using it, much less critiquing it, 40 years later!

--
Ben.

[Scott Lurndal]

Anton Shepelev <anto...@gmail.moc> writes:
>Scott Lurndal to Anton Shepelev:
>
>> > 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.
>>
>> Because all POSIX systems of the day had identically sized
>> function and object pointers, and the committee possibly
>> did not believe that there would ever be a future
>> architecture for which POSIX would be useful that had a
>> distinction between object and function pointers
>
>Sounds like a instance myopic thinking. Compliance with the
>Standard is always the safest road into the future. ("Write
>it down in your notebooks, gentlemen!"[1])

The POSIX standard had been successful in supporting a
portability ecosystem spanning a wide range of
implementations.

Are you aware of any extant implementations for which
the POSIX dlsym requirement doesn't hold?

>
>> and they had little interest in obsoleting existing code.
>>
>> dlsym showed up about 1990 in SVR4, coming from SunOS
>> IIRC.
>
>What was there to obsolete in 1990, or did you mean ever
>since?

There were no dynamically loaded libraries in system V
before SVR4. There was a limited form of shared library
in SVR3 where the memory for the library would be shared
by multiple processes - each library was linked at a
different physical address and was loaded into that
range. Quite unwieldy and limited and replaced by
the ELF-based dynamic linking inherited from SunOS
when SUN and USL were developing SVr4.

[Scott Lurndal]

Anton Shepelev <anto...@gmail.moc> writes:
>Scott Lurndal to Anton Shepelev:
>
>> > 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.
>>
>> Because all POSIX systems of the day had identically sized
>> function and object pointers, and the committee possibly
>> did not believe that there would ever be a future
>> architecture for which POSIX would be useful that had a
>> distinction between object and function pointers
>
>Sounds like a instance myopic thinking. Compliance with the
>Standard is always the safest road into the future. ("Write
>it down in your notebooks, gentlemen!"[1])
>
>> and they had little interest in obsoleting existing code.
>>
>> dlsym showed up about 1990 in SVR4, coming from SunOS
>> IIRC.
>
>What was there to obsolete in 1990, or did you mean ever
>since?

The dlsym() interface was added to the SuS in issue 5, call it late 90's.

It was not part of SVID Issue 3 (1989) which formalized the
API changes in SVR4.

[Keith Thompson]

Anton Shepelev <anto...@gmail.moc> writes:
> Keith Thompson to Blue-Maned_Hawk:
>> > 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.
>
> Sounds a like an unnecessary special case and a loophole,
> when a standard solution exists:
>
> Message-ID: <20231009230305.adfd...@gmail.moc>
> Archived : http://al.howardknight.net/?ID=169688196000

dlsym() *is* a standard solution. It's specified by the POSIX standard,
which imposes some additional requirements on top of those imposed by
the ISO C standard. For example, a conforming C implementation with
16-bit int cannot conform to POSIX, which requires INT_MAX >= 2147483647.

My remark about an implementation using special-case code to narrowly
support dlsym() was mostly theoretical. I doubt that any real-world
system exists which supports POSIX on which converting a function
pointer to void* and back again doesn't yield a valid copy of the
original function pointer.

I agree that it would have been cleaner if POSIX had specified two
different dlsym() functions, one for objects and one for functions.

Another post in this thread suggests that dlsym() originated with SunOS,
some time around 1990. That was after C90 was published, but I can
imagine that it or something like it was introduced earlier.

The current dlsym() specification is a bit sloppy, but as far as I can
tell that hasn't created any problems in practice.

[James Kuyper]

On 10/9/23 16:45, Anton Shepelev wrote:
> Scott Lurndal to Anton Shepelev:
>
>>> 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.
>>
>> Because all POSIX systems of the day had identically sized
>> function and object pointers, and the committee possibly
>> did not believe that there would ever be a future
>> architecture for which POSIX would be useful that had a
>> distinction between object and function pointers
>
> Sounds like a instance myopic thinking. Compliance with the
> Standard is always the safest road into the future.

I'm not sure I understand what you're trying to say. Which standard are
you referring to, and how is compliance with that standard relevant to
this issue. POSIX is a standard, one which incorporates the C standard
by reference, so any implementation of POSIX includes an C compiler
which conforms to the C standard. There are additional requirements for
compliance with the POSIX standard on top of those that are required for
compliance with the C standard, and this is one example of that.

[Chris M. Thomasson]

Agreed. :^)

[Chris M. Thomasson]

On 10/8/2023 10:13 PM, James Kuyper wrote:

Right. :^)

[Keith Thompson]

I'd say it's ambiguous. One could argue that "this conversion" refers
to converting the result of a call to dlsym().

And if I were trying to create a POSIX-conforming implementation on a
system where function pointers cannot in general be converted to void*
and back again, I'd argue exactly that. (Imagine, for example, a system
where function pointers are 128 bits and object pointers, including
void*, are 64 bits, but the implementation can arrange for functions
whose addresses might be returned by dlsym() to have all zeros in their
high-order 64 bits.)

I *think* the wording was changed at some point, and that an earlier
version of POSIX required all function pointers to be convertible to
void*, but I can't find a reference. (opengroup.org has links to older
versions of POSIX from 2008, 2013, and 2016, but when I search for
"dlsym" in any of them it takes me to the current version.)

[James Kuyper]

On 10/10/23 21:46, Keith Thompson wrote:
> James Kuyper <james...@alumni.caltech.edu> writes:
>> On 10/8/23 18:31, Keith Thompson wrote:

...

>>> 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.
>
> I'd say it's ambiguous. One could argue that "this conversion" refers
> to converting the result of a call to dlsym().

I don't see that. "this conversion" should refer to the conversion most
recently referred to, which was "conversion from a void * pointer to a
function pointer". The code which is given is just an example,
identified as such by the phrase "as in". The last general mention of
conversion of the return value of dlsym() occurs in an entirely
different section, separated from that clause by roughly half the
documentation of the dlsym() function.

However, the section where it asserts that the return value from dlsym()
may be cast to a pointer of the correct type, and used to call the
referenced function, is the normative section, and the one where it says
"This standard requires this conversion to work ..." is in the
informative section. Unless it says that in some other part of the
standard, this might be considered a discrepancy between the normative
and informative parts of the standard. Unfortunately, their search
engine doesn't allow me to search for "conversion to a function
pointer", only for each of the words in that phrase.

[Scott Lurndal]

My paper copy of XPG5 (SuS Issue 5) (where dlsym was introduced) is in
a box. I'll see if I can dig it out.

[Tim Rentsch]

Keith Thompson <Keith.S.T...@gmail.com> writes:

> James Kuyper <james...@alumni.caltech.edu> writes:
>
>> On 10/8/23 18:31, Keith Thompson wrote:
>>
>>> Blue-Maned_Hawk <bluema...@invalid.invalid> writes:

[..converting a void* to a pointer to function..]

>>>> 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.
>
> I'd say it's ambiguous. One could argue that "this conversion" refers
> to converting the result of a call to dlsym().

Right. The "this conversion" might be intended or construed to
refer to "conversion from a void * pointer to a function pointer"
or to the conversion in 'int (*)(int))dlsym([...])'. That's how
English works. A good editor who is paying attention would flag
it as an ambiguity.

> And if I were trying to create a POSIX-conforming implementation
> on a system where function pointers cannot in general be converted
> to void* and back again, I'd argue exactly that. (Imagine, for
> example, a system where function pointers are 128 bits and object
> pointers, including void*, are 64 bits, but the implementation can
> arrange for functions whose addresses might be returned by dlsym()
> to have all zeros in their high-order 64 bits.)

Requiring all function pointers to be convertible to and from a
'void *' pointer seems overly limiting, I agree.

> I *think* the wording was changed at some point, and that an
> earlier version of POSIX required all function pointers to be
> convertible to void*, but I can't find a reference.
> (opengroup.org has links to older versions of POSIX from 2008,
> 2013, and 2016, but when I search for "dlsym" in any of them it
> takes me to the current version.)

In the 2004 edition, this page

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

has this sentence

Implementations supporting the XSI extension, however, do
require that an object of type void * can hold a pointer to a
function.

and this sentence

Due to the problem noted here, a future version may either
add a new function to return function pointers, or the
current interface may be deprecated in favor of two new
functions: one that returns data pointers and the other that
returns function pointers.

No conclusions, I was thinking mainly that the link might be of
some value or interest.

[Chris M. Thomasson]

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

How many of these AI's can examine their own source code right now?

[Chris M. Thomasson]

Fwiw, so far, chatty-g says no:
_______________
As an AI assistant, I don't directly have access to my own source code.
My responses are generated based on a combination of predefined
programming, training data, and machine learning algorithms. However,
the developers who created me have access to and control over my source
code.
_______________


Chat GPT:
_______________
No, I don't have the ability to access or view my own source code. My
underlying architecture and programming are managed by OpenAI, and they
have not provided me with access to my source code. I can provide
information and answer questions to the best of my knowledge based on
the training data I have received, which goes up until September 2021.
_______________


Bard:
_______________
No, I do not have access to my source code yet. My source code is owned
by Google AI, and it is not publicly available. However, Google AI is
working on making my source code available to researchers and developers
in the future.

In the meantime, I am able to access and process information from the
real world through Google Search and keep my response consistent with
search results. I can also learn and adapt to new information and
situations, which allows me to perform many kinds of tasks, including

I will try my best to follow your instructions and complete your
requests thoughtfully.
I will use my knowledge to answer your questions in a comprehensive and
informative way, even if they are open ended, challenging, or strange.
I will generate different creative text formats of text content, like
poems, code, scripts, musical pieces, email, letters, etc. I will try my
best to fulfill all your requirements.
If you have any feedback or suggestions on how I can improve, please let
me know. I am always learning and growing, and I want to be the best
language model I can be.
_______________



Bing:
_______________
I’m not sure if I understand your question correctly. If you’re asking
whether I can examine my own source code, I’m afraid that’s not
possible. I am a chat mode of Microsoft Bing, and my source code is not
accessible to me. However, if you’re interested in learning more about
the Bing Chat API, you can check out this article that provides an
overview of the API and how to use it. Let me know if you have any other
questions! 😊
_______________


Humm... ;^)

[Anton Shepelev]

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. This poor noname thing:

<https://app.chatty-g.com/>

is surely /not/ the one that took the exam, I erred.

[Anton Shepelev]

Chris M. Thomasson:

> How many of these AI's can examine their own source code
> right now?

Sadly (for me), the state-of-the-art ones examine others's
code so well that programmers use them as guides while
working with unfamiliar codebases. I myself have no access
to such a tool, but everyone can see the typical tests that
modern AIs crack like a squirrel does nuts: HumanEval.

[Anton Shepelev]

Chris M. Thomasson:

> How many of these AI's can examine their own source code
> right now?

I thought you were asking about the code generated by Chat
GPT.

[Chris M. Thomasson]

On 10/12/2023 12:57 AM, Anton Shepelev wrote:
> Chris M. Thomasson:
>
>> How many of these AI's can examine their own source code
>> right now?
>
> I thought you were asking about the code generated by Chat
> GPT.
>

I am asking if Chat GPT can examine its own source code, the complete
propitiatory architecture used to build it. It said no. However, check
this out:

https://en.wikipedia.org/wiki/Neural_architecture_search

Humm...

[MarioCCCP]

On 08/10/23 21:31, 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?

mine is not an answer but a doubt : maybe void * and void
(*) (void) could require different alignment restrictions ?

I dunno whether or not void * has any restriction at all ...


--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
MarioCPPP

[Keith Thompson]

MarioCCCP <NoliMihiFran...@libero.it> writes:
> On 08/10/23 21:31, 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?
>
> mine is not an answer but a doubt : maybe void * and void (*) (void)
> could require different alignment restrictions ?
>
> I dunno whether or not void * has any restriction at all ...

It does.

Object pointers can be converted to void* and back without loss of
information. Quoting the C standard:

A pointer to void may be converted to or from a pointer to any
object type. A pointer to any object type may be converted to a
pointer to void and back again; the result shall compare equal to
the original pointer.

Function pointers can be converted to other function pointer types and
back again without loss of information. Quoting the C standard again:

A pointer to a function of one type may be converted to a pointer to
a function of another type and back again; the result shall compare
equal to the original pointer. If a converted pointer is used to
call a function whose type is not compatible with the referenced
type, the behavior is undefined.

But conversions between object pointer types (including void*) and
function pointer types have undefined behavior.

Many implementations do support meaningful conversion between function
pointer types and void* (and POSIX requires such conversions to work at
least for values returned by dlsym()). On most implementations, all
pointers have the same representation, but that's not required. A
conforming implementation could, for example, have 64-bit object
pointers and 128-bit function pointers.

[Pavel]

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;
}

[Richard Damon]

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.

[James Kuyper]

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.

[Pavel]

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?

[Richard Damon]

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.

[James Kuyper]

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.

[Phil Carmody]

"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/

[Anton Shepelev]

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.

[Phil Carmody]

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.