Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #92398 > unrolled thread

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

Back to article view | Back to comp.lang.c++

Contents

  “ChattyG takes a college freshman C/C++ programming exam” Lynn McGuire <lynnmcguire5@gmail.com> - 2023-10-05 17:40 -0500
    Re: “ChattyG takes a college freshman C/C++ programming exam” "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-05 15:57 -0700
    Re: “ChattyG takes a college freshman C/C++ programming exam” Christian Gollwitzer <auriocus@gmx.de> - 2023-10-06 07:36 +0200
      Re: “ChattyG takes a college freshman C/C++ programming exam” "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-06 11:59 -0700
    Re: “ChattyG takes a college freshman C/C++ programming exam” Anton Shepelev <anton.txt@gmail.moc> - 2023-10-07 23:54 +0300
      Re: “ChattyG takes a college freshman C/C++ programming exam” jak <nospam@please.ty> - 2023-10-08 09:42 +0200
        Re: “ChattyG takes a college freshman C/C++ programming exam” James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-10-08 04:27 -0400
        Re: “ChattyG takes a college freshman C/C++ programming exam” Anton Shepelev <anton.txt@gmail.moc> - 2023-10-08 12:55 +0300
          Re: “ChattyG takes a college freshman C/C++ programming exam” Anton Shepelev <anton.txt@gmail.moc> - 2023-10-08 13:06 +0300
          Re: “ChattyG takes a college freshman C/C++ programming exam” candycanearter07 <no@thanks.net> - 2023-10-08 06:22 -0500
            Re: “ChattyG takes a college freshman C/C++ programming exam” Anton Shepelev <anton.txt@gmail.moc> - 2023-10-08 15:03 +0300
              Re: “ChattyG takes a college freshman C/C++ programming exam” Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-10-15 15:51 -0400
                Re: “ChattyG takes a college freshman C/C++ programming exam” Richard Damon <richard@damon-family.org> - 2023-10-15 17:53 -0400
                Re: “ChattyG takes a college freshman C/C++ programming exam” James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-10-16 00:07 -0400
                  Re: “ChattyG takes a college freshman C/C++ programming exam” Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-10-16 22:01 -0400
                    Re: “ChattyG takes a college freshman C/C++ programming exam” Richard Damon <richard@damon-family.org> - 2023-10-16 22:41 -0400
                    Re: “ChattyG takes a college freshman C/C++ programming exam” James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-10-17 12:22 -0400
            Re: “ChattyG takes a college freshman C/C++ programming exam” "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-08 12:31 -0700
              Re: “ChattyG takes a college freshman C/C++ programming exam” Richard Damon <news.x.richarddamon@xoxy.net> - 2023-10-08 21:17 -0400
                Re: “ChattyG takes a college freshman C/C++ programming exam” James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-10-09 01:13 -0400
                  Re: “ChattyG takes a college freshman C/C++ programming exam” "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-10 12:18 -0700
              Re: “ChattyG takes a college freshman C/C++ programming exam” MarioCCCP <NoliMihiFrangereMentulam@libero.it> - 2023-10-13 11:22 +0200
                Re: “ChattyG takes a college freshman C/C++ programming exam” Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-10-13 10:04 -0700
          Re: “ChattyG takes a college freshman C/C++ programming exam” Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-10-08 13:54 +0100
          Re: “ChattyG takes a college freshman C/C++ programming exam” James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-10-08 11:25 -0400
            Re: “ChattyG takes a college freshman C/C++ programming exam” Anton Shepelev <anton.txt@gmail.moc> - 2023-10-08 20:07 +0300
          Re: “ChattyG takes a college freshman C/C++ programming exam” Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2023-10-08 16:37 +0000
            Re: “ChattyG takes a college freshman C/C++ programming exam” Anton Shepelev <anton.txt@gmail.moc> - 2023-10-08 20:05 +0300
              Re: “ChattyG takes a college freshman C/C++ programming exam” James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-10-09 01:13 -0400
                Re: “ChattyG takes a college freshman C/C++ programming exam” "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-09 13:30 -0700
                  Re: Re: “ChattyG takes a college freshman C/C++ programming exam” scott@slp53.sl.home (Scott Lurndal) - 2023-10-09 20:33 +0000
                    Re: “ChattyG takes a college freshman C/C++ programming exam” "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-10 12:04 -0700
              Re: “ChattyG takes a college freshman C/C++ programming exam” Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2023-10-09 12:17 +0000
                Re: “ChattyG takes a college freshman C/C++ programming exam” Anton Shepelev <anton.txt@gmail.moc> - 2023-10-09 23:03 +0300
                  Re: “ChattyG takes a college freshman C/C++ programming exam” scott@slp53.sl.home (Scott Lurndal) - 2023-10-09 20:30 +0000
                    Re: “ChattyG takes a college freshman C/C++ programming exam” Anton Shepelev <anton.txt@gmail.moc> - 2023-10-09 23:45 +0300
                      Re: “ChattyG takes a college freshman C/C++ programming exam” scott@slp53.sl.home (Scott Lurndal) - 2023-10-09 21:21 +0000
                      Re: “ChattyG takes a college freshman C/C++ programming exam” scott@slp53.sl.home (Scott Lurndal) - 2023-10-09 21:26 +0000
                      Re: “ChattyG takes a college freshman C/C++ programming exam” James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-10-09 22:41 -0400
                  Re: “ChattyG takes a college freshman C/C++ programming exam” Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-10-09 21:47 +0100
            Re: “ChattyG takes a college freshman C/C++ programming exam” Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-10-08 15:31 -0700
              Re: “ChattyG takes a college freshman C/C++ programming exam” James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-10-09 01:12 -0400
                Re: “ChattyG takes a college freshman C/C++ programming exam” Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-10-10 18:46 -0700
                  Re: “ChattyG takes a college freshman C/C++ programming exam” James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-10-11 01:14 -0400
                  Re: “ChattyG takes a college freshman C/C++ programming exam” scott@slp53.sl.home (Scott Lurndal) - 2023-10-11 13:47 +0000
                  Re: “ChattyG takes a college freshman C/C++ programming exam” Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-10-11 07:56 -0700
              Re: “ChattyG takes a college freshman C/C++ programming exam” Anton Shepelev <anton.txt@gmail.moc> - 2023-10-09 23:06 +0300
                Re: “ChattyG takes a college freshman C/C++ programming exam” Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-10-09 17:15 -0700
        Re: “ChattyG takes a college freshman C/C++ programming exam” James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-10-08 11:08 -0400
    Re: “ChattyG takes a college freshman C/C++ programming exam” "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-11 21:06 -0700
      Re: “ChattyG takes a college freshman C/C++ programming exam” "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-11 21:10 -0700
      Re: “ChattyG takes a college freshman C/C++ programming exam” Anton Shepelev <anton.txt@g{oogle}mail.com> - 2023-10-12 10:56 +0300
      Re: “ChattyG takes a college freshman C/C++ programming exam” Anton Shepelev <anton.txt@g{oogle}mail.com> - 2023-10-12 10:57 +0300
        Re: “ChattyG takes a college freshman C/C++ programming exam” "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-12 12:59 -0700
    Re: “ChattyG takes a college freshman C/C++ programming exam” Anton Shepelev <anton.txt@g{oogle}mail.com> - 2023-10-12 10:53 +0300
      Re: “ChattyG takes a college freshman C/C++ programming exam” Phil Carmody <pc+usenet@asdf.org> - 2023-10-23 15:39 +0300
        Re: “ChattyG takes a college freshman C/C++ programming exam” Anton Shepelev <anton.txt@g{oogle}mail.com> - 2023-10-23 16:45 +0300

Page 3 of 3 — ← Prev page 1 2 [3]

#92453

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

[toc] | [prev] | [next] | [standalone]

#92458

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.

[toc] | [prev] | [next] | [standalone]

#92554

James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> 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.

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

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

[toc] | [prev] | [next] | [standalone]

#92562

On 10/10/23 21:46, Keith Thompson wrote:
> James Kuyper <jameskuyper@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.

[toc] | [prev] | [next] | [standalone]

#92577

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>> 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.
>
>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.)

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.

[toc] | [prev] | [next] | [standalone]

#92578

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>
>> On 10/8/23 18:31, Keith Thompson wrote:
>>
>>> Blue-Maned_Hawk <bluemanedhawk@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.

[toc] | [prev] | [next] | [standalone]

#92479

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.adfd0d80c146dc966ab22443@gmail.moc>
   Archived  : http://al.howardknight.net/?ID=169688196000

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

[toc] | [prev] | [next] | [standalone]

#92497

Anton Shepelev <anton.txt@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.adfd0d80c146dc966ab22443@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.

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

[toc] | [prev] | [next] | [standalone]

#92443

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

[toc] | [prev] | [next] | [standalone]

#92594

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?

[toc] | [prev] | [next] | [standalone]

#92595

On 10/11/2023 9:06 PM, Chris M. Thomasson wrote:
> 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?
> 

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

[toc] | [prev] | [next] | [standalone]

#92617

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.

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

[toc] | [prev] | [next] | [standalone]

#92618

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.

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

[toc] | [prev] | [next] | [standalone]

#92629

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

[toc] | [prev] | [next] | [standalone]

#92616

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.

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

[toc] | [prev] | [next] | [standalone]

#94741

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

[toc] | [prev] | [next] | [standalone]

#94743

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

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.c++

csiph-web