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

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

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

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

I offer a dissenting view.

I have two complaints. One is that in most cases people use
"exotic" typology when regular old ASCII would do just fine. If
someone wants to express twice as much or three times as much, it
seems perfectly okay to write "2x" or "3x" rather than insisting
on using a mathematical times symbol for the x. If someone wants
to show a list of items, using * rather than insisting on using
bullet characters is IMO not just acceptable but actually better.
Messages in the newsgroups should emphasize content over form;
fancy typology has an air of advertising copy, which is certainly
not what I want to read in comp.<whatever>.

My second complaint has to do with being forced to use new tools
just "because it is there" or "more modern is always better".
Bah, humbug. Quoted printable? Flowed? No line breaks
expecting wrapping will be done "automatically"? I want plain
text, thank you very much, but of course the fashion nowadays is
HTML emails. Yuck. I got an email recently where the content
could have been given in perhaps four or five short lines of
regular text, but instead the email had a PDF attachment that
showed the "message" as an image. An image! Awful. And the
worst thing is, it never stops. There is always some new tool,
some new technology, that I just /have/ to use, to keep up with
the never-ending "advance" of technology. Web sites that I have
used for years without any problems tell me that now to see their
pages I need to upgrade my browser. Forget it! I know that sort
of nonsense is inevitable in most of the internet, but I most
sincerely hope that attitude doesn't take root in Usenet.

One final note - your own news posting says

Content-Type: text/plain

with no mention of UTF-8 (or other), or Content-Transfer-Encoding.
To which I say, Good!

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

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

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

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

as the pointer needs to act just like the function.

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

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

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

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

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

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

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

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

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

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

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> 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.
>
> I offer a dissenting view.
>
> I have two complaints. One is that in most cases people use
> "exotic" typology when regular old ASCII would do just fine.

Well, so far, that is not a dissenting view in that I agree. I suppose
you mean one should not even encourage the possibility of doing so by
keeping the character set limited. If so, that /is/ a dissenting view,
but I'm guessing what you mean there.

> If
> someone wants to express twice as much or three times as much, it
> seems perfectly okay to write "2x" or "3x" rather than insisting
> on using a mathematical times symbol for the x. If someone wants
> to show a list of items, using * rather than insisting on using
> bullet characters is IMO not just acceptable but actually better.
> Messages in the newsgroups should emphasize content over form;
> fancy typology has an air of advertising copy, which is certainly
> not what I want to read in comp.<whatever>.

The problem is the linkage. We now have a way to write lots of things
correctly -- pronunciations, currencies, people's names, places and so
on. There's a cost to ruling out the abuse of • when * would do.

> My second complaint has to do with being forced to use new tools
> just "because it is there" or "more modern is always better".

Again, not a dissenting view. Those are, I agree, terrible reasons for
using Unicode. I am surprised you think I might hold it!

> Bah, humbug. Quoted printable? Flowed? No line breaks
> expecting wrapping will be done "automatically"?

Did I say anything about these?

> I want plain
> text, thank you very much,

So do I. The point I was making is that what constitutes "plain text"
is not somehow a matter of fact. There was a time when anything but a
very limited character set was "plain". For some people, "plain" is an
ISO 8859 encoding that let's them write their own name! That "plain
text" is 7-but ASCII is a cultural invention, large pushed by people for
whom it is adequate.

> but of course the fashion nowadays is
> HTML emails. Yuck. I got an email recently where the content
> could have been given in perhaps four or five short lines of
> regular text, but instead the email had a PDF attachment that
> showed the "message" as an image. An image! Awful. And the
> worst thing is, it never stops. There is always some new tool,
> some new technology, that I just /have/ to use, to keep up with
> the never-ending "advance" of technology. Web sites that I have
> used for years without any problems tell me that now to see their
> pages I need to upgrade my browser. Forget it! I know that sort
> of nonsense is inevitable in most of the internet, but I most
> sincerely hope that attitude doesn't take root in Usenet.

Presumably you are now joking, since there's no possible reason to think
that I favour your dystopian picture, nor that using Unicode will
inevitable lead to text in an image in a PDF.

> One final note - your own news posting says
>
> Content-Type: text/plain
>
> with no mention of UTF-8 (or other), or Content-Transfer-Encoding.
> To which I say, Good!

Yes. If you are surprised by that, it can only be because you've
attributed to me a whole collection of opinions I don't have. Minimal
sets with maximal reach are best when they suffice, and I don't use
Unicode for the sake of it.

I use a client where the Content-Type is chosen from a list I specify.
A while back, that list included the ISO-8859 characters set that let me
write to my family in French and Spanish (I use the same client for
email and Usenet). Now, I just use ASCII with a fall-back to UTF-8 so
if ASCII suffices, it will be used. If that configuration is still
working, my use of • for illustration will have forced UTF-8 to be used.

--
Ben.

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

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

typedef void* (*vfptr_t)(int);

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

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

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

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

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

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

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

vfptr_t fptr2 = fptr(6);

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

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

That is an improvement, because it improves the validity checks that the
compiler can perform. However, it doesn't affect the validity of the
code. A declaration that is not part of the function definition, and
which gives no parameter list, is compatible with a function definition
that does define parameters, whether by using a function prototype or by
the older K&R method. That's not a problem - it's the incompatible
return types that render the two function types incompatible, and
therefore give the code undefined behavior.

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

To say that "this works as well", is misleading. Both have undefined
behavior due to the call to fptr(6), so it would be more accurate to say
"this fails just as badly".

Note: if, by "this works as well", you mean that it produces the
behavior you expected, that's irrelevant. You had no justification for
expecting that behavior; it's not guaranteed by the standard, and I
doubt you'll find anything in the compiler's documentation that
guarantees it either. 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 flaw in your program.

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

That's not the call that has undefined behavior. That call is done using
a function designator that is compatible with the function's definition.
The call that uses an incompatible type is "fptr(6);", which does not do
anything with the value returned by the function, and yet still has
undefined behavior because of the incompatible return types.

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.

This is quotable, printable, and mountable.

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

Ben Bacarisse:

> That "plain text" is 7-but ASCII is a cultural invention,
> large pushed by people for whom it is adequate.

Yes, it is a huge cultural stample, embraced (at one time)
by systems and software and people. Hence ASCII-art.

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

On 17/10/2023 13:25, Anton Shepelev wrote:
> Ben Bacarisse:
>
>> That "plain text" is 7-but ASCII is a cultural invention,
>> large pushed by people for whom it is adequate.
>
> Yes, it is a huge cultural stample, embraced (at one time)
> by systems and software and people. Hence ASCII-art.
>

You say "embraced", other people say "tolerated because there were not
good alternatives".

ASCII is, by its very definition, American-centred. That's not
unreasonable, given that the USA has been a major source of a great deal
of the development of the computing world. (And the it's not bad for
use in the UK either - the £ sign is about the only important missing
character for basic use.)

But the world is bigger than the USA. Other people want different
characters for different languages, symbols, diacriticals, alphabets,
etc. What is "plain text" to someone writing English has different
requirements from "plain text" to someone writing in Norwegian, Greek,
or Mandarin. And sometimes people want to use additional symbols to
make their writing clearer.

For Usenet, as for a lot of programming, it makes sense to stick to
ASCII for the most part. I would not write “text” with nice opening and
closing quotation marks, I'd write "text" with plain marks - Usenet
posts are never going to be typographical masterpieces. And in
programming, I'd write "pi" rather than "π", because I know some people
have to work with much more limited keyboard layouts.

But if non-ASCII characters are needed to make the writing clear, or to
spell words or names correctly in their language, I will use UTF-8
characters without hesitation. It's been the standard for long enough
that few people have trouble with it, and it is vastly better than any
alternative character encoding beyond ASCII.

If you look at the history of character encodings, you see that there
are vast numbers of them created over the decades. That is because
7-bit ASCII was /not/ embraced - it is a limited subset of characters
that is adequate for many purposes, but very far from ideal for many
more. (But I'm very glad it was 7-bit - that is what allowed UTF-8 to
work so well.)

It is, however, pretty idiotic to use UTF-8 along with a client that
does not support it!

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>
>>> 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.
>>
>> I offer a dissenting view.
>>
>> I have two complaints. One is that in most cases people use
>> "exotic" typology when regular old ASCII would do just fine.
>
> Well, so far, that is not a dissenting view in that I agree.

Reading ahead, I see that we mostly agree. I'll give some
responses here and there, mostly for clarification I think.

> I suppose you mean one should not even encourage the possibility
> of doing so by keeping the character set limited. If so, that
> /is/ a dissenting view, but I'm guessing what you mean there.

I'm not trying to "contain" UTF-8. That cat is out of the bag,
never to return. I just don't want people to use it when they
don't have to.

>> If
>> someone wants to express twice as much or three times as much, it
>> seems perfectly okay to write "2x" or "3x" rather than insisting
>> on using a mathematical times symbol for the x. If someone wants
>> to show a list of items, using * rather than insisting on using
>> bullet characters is IMO not just acceptable but actually better.
>> Messages in the newsgroups should emphasize content over form;
>> fancy typology has an air of advertising copy, which is certainly
>> not what I want to read in comp.<whatever>.
>
> The problem is the linkage. We now have a way to write lots of
> things correctly -- pronunciations, currencies, people's names,
> places and so on. There's a cost to ruling out the abuse of
> [bullet?] when * would do.

I don't mean to rule out anything. I just want people to be
considerate of others, and not assume that something works in
my newsreader just because it works in theirs.

>> My second complaint has to do with being forced to use new tools
>> just "because it is there" or "more modern is always better".
>
> Again, not a dissenting view. Those are, I agree, terrible
> reasons for using Unicode. I am surprised you think I might hold
> it!

It was a general complaint; I didn't (and don't) mean to
attribute that attitude to you.

>> Bah, humbug. Quoted printable? Flowed? No line breaks
>> expecting wrapping will be done "automatically"?
>
> Did I say anything about these?

No, you didn't, but they are part and parcel of the same problem.
So in a sense I am overreacting. My complaint though is more a
reaction to a general attitude, not one specifically tied to
non-ASCII characters. I believe these trends are not independent.

>> I want plain
>> text, thank you very much,
>
> So do I. The point I was making is that what constitutes "plain
> text" is not somehow a matter of fact. There was a time when
> anything but a very limited character set was "plain". For some
> people, "plain" is an ISO 8859 encoding that let's them write
> their own name! That "plain text" is 7-but ASCII is a cultural
> invention, large pushed by people for whom it is adequate.

I don't completely agree that it is a cultural invention.
Network effects matter. The most common language in the world is
English, and that is not a coincidence. In any case, whatever
the cause, we can recognize the state of affairs and not be too
cavalier about changing them. I want evolution, not revolution.

>> but of course the fashion nowadays is
>> HTML emails. Yuck. I got an email recently where the content
>> could have been given in perhaps four or five short lines of
>> regular text, but instead the email had a PDF attachment that
>> showed the "message" as an image. An image! Awful. And the
>> worst thing is, it never stops. There is always some new tool,
>> some new technology, that I just /have/ to use, to keep up with
>> the never-ending "advance" of technology. Web sites that I have
>> used for years without any problems tell me that now to see their
>> pages I need to upgrade my browser. Forget it! I know that sort
>> of nonsense is inevitable in most of the internet, but I most
>> sincerely hope that attitude doesn't take root in Usenet.
>
> Presumably you are now joking, since there's no possible reason to
> think that I favour your dystopian picture, nor that using Unicode
> will inevitable lead to text in an image in a PDF.

Here again, my comments are not meant to be directed at you in
particular (and probably not at all), and I think these various
forces are not independent. Oh no, am I becoming a conspiracy
theorist? ;)

>> One final note - your own news posting says
>>
>> Content-Type: text/plain
>>
>> with no mention of UTF-8 (or other), or Content-Transfer-Encoding.
>> To which I say, Good!
>
> Yes. If you are surprised by that, it can only be because you've
> attributed to me a whole collection of opinions I don't have.
> Minimal sets with maximal reach are best when they suffice, and I
> don't use Unicode for the sake of it.

Not surprised, just amused. Good to hear the sentiments in your
last sentence.

> I use a client where the Content-Type is chosen from a list I
> specify. A while back, that list included the ISO-8859 characters
> set that let me write to my family in French and Spanish (I use
> the same client for email and Usenet). Now, I just use ASCII with
> a fall-back to UTF-8 so if ASCII suffices, it will be used. If
> that configuration is still working, my use of [bullet?] for
> illustration will have forced UTF-8 to be used.

Yes, I see that it did. And as expected we are more in agreement
than not (at least I think we are!).

Incidentally, the character I have translated as [bullet?] comes out
in my newreader as a question mark character.

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.