Path: csiph.com!weretis.net!feeder8.news.weretis.net!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c++ Subject: Re: =?utf-8?Q?=E2=80=9CChattyG?= takes a college freshman C/C++ programming =?utf-8?Q?exam=E2=80=9D?= Date: Wed, 11 Oct 2023 07:56:18 -0700 Organization: A noiseless patient Spider Lines: 80 Message-ID: <86sf6hb431.fsf@linuxsc.com> References: <20231007235448.25c4986f123c88ff65d2f103@gmail.moc> <20231008125543.518cab44cdefed7e8af393c8@gmail.moc> <87cyxovj92.fsf@nosuchdomain.example.com> <87lecaszhf.fsf@nosuchdomain.example.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: dont-email.me; posting-host="c9974d524a342450c72757464b9d47a6"; logging-data="1993712"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18MhqJQVhip0TUFcVmiaYJ5l0zC2gqF+RE=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:h8NzRLyaQenBggIDLc6bXZxXd/4= sha1:OUb9KO/WenCG4Za3gusAbp7zdXg= Xref: csiph.com comp.lang.c++:92578 Keith Thompson writes: > James Kuyper writes: > >> On 10/8/23 18:31, Keith Thompson wrote: >> >>> Blue-Maned_Hawk 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.