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

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

On 10/8/2023 10:13 PM, James Kuyper wrote:
> 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.
>

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.

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>On 10/8/2023 10:13 PM, James Kuyper wrote:
>> 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.
>>
>
>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.

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

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/

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

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

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

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

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

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.

On 10/9/2023 1:33 PM, Scott Lurndal wrote:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>> On 10/8/2023 10:13 PM, James Kuyper wrote:
>>> 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.
>>>
>>
>> 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.
>
> If you're using dlsym in your application, you are unlikely to be using
> a non-POSIX system in the first place.

Agreed. :^)

On 10/8/2023 10:13 PM, James Kuyper wrote:
> 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
>
>

Right. :^)

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

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.

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.

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.

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?

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

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

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

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

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

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

MarioCCCP <NoliMihiFrangereMentulam@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.

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

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