Path: ...!news.mixmin.net!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Anton Shepelev <anton.txt@gmail.moc>
Newsgroups: comp.lang.c++,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: Mon, 9 Oct 2023 23:03:05 +0300
Organization: A noiseless patient Spider
Lines: 60
Message-ID: <20231009230305.adfd0d80c146dc966ab22443@gmail.moc>
References: <ufne0r$15ple$1@dont-email.me>
	<20231007235448.25c4986f123c88ff65d2f103@gmail.moc>
	<uftmh9$2vieq$1@dont-email.me>
	<20231008125543.518cab44cdefed7e8af393c8@gmail.moc>
	<pan$93d59$b5109882$fbf405c8$d4bea16f@invalid.invalid>
	<20231008200536.2aebe46b71bae8b879b5bddb@gmail.moc>
	<pan$da5cd$33b40da2$e72bf6b3$e30efcdc@invalid.invalid>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Info: dont-email.me; posting-host="404cc1cc3d5d5d1907a85a6573344343";
	logging-data="119227"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19MAdOT5Xqqkjv3dJtGyqayoFpWQmbzLM4="
Cancel-Lock: sha1:n/iuEewM1Hqtv3zuam+KTJY/iNM=
X-Newsreader: Sylpheed 3.7.0 (GTK+ 2.24.30; i686-pc-mingw32)
Bytes: 3614

Blue-Maned_Hawk to Anton Shepelev:

> > Blue-Maned_Hawk:
> > [Unicode em-dash replaced with --]
>
> Why?

Oh, it just doesn't go with Usenet, stylistically and
aesthetically.  English plain-text is must like
code -- 7-bit-clean.  And like code (e.g. for Troff or
LaTeX), there are convensions for dashes, /italic/ text,
<URLs>, &c.  Your signature is a mess of Unicode
characters -- terrible :-!

> > > It mayn't be supported in standard C, but it's a
> > > common extension--in fact, POSIX _requires_ it in
> > > order for the dlsym subroutine to work.
> >
> > How so, when casing the return value (from a different
> > function pointer) does not solve the problem?
>
> I was not referring to functions returning pointers to
> themselves in the quoted part of my message.  I was
> referring to void * being castable to a function pointer.

Yes, and I asked why the authors of that API decided not to
use the casing that is guarranteed to work, preferring the
dubious casing of void* to function pointers.  If /I/ were
the designer (should you be afraid?), I should make it two
functions:

   void *        dlsym_o(void *restrict handle, const char *restrict name);
   void(*)(void) dlsym_f(void *restrict handle, const char *restrict name);

because the caller usually knows what he seeks.  If he
doesn't, let it be a single function with a compund return
type.  I am not sure what a good way to do it would be,
however, because, having to declare a struct, (with possibly
an union inside) and an enum just for this function may be
bloat, yet:--

   enum dlsym_type {dsOBJ, dsFUN, dsNA}; /* the 3rd member optional */

   struct dlsym_info
   {  char            is_found; /* flag, optional    */
      enum dlsym_type type    ; /* optional          */
      void *          obj_ptr ; /* NULL if not found */
      void(*)(void)   fun_ptr ; /* NULL if not found */
   }

`optional' above means the element may be omitted from the
interface. For example, dsNA and .is_found are mutually
exclusive, and both the flag and the enum may be done away
with by requiring that the caller use whichever pointer is
not NULL, and consider the symbol not found if both are
NULL.

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