Re: [PATCH 09/13] parse-options API: don't restrict OPT_SUBCOMMAND() to one *_fn type

["René Scharfe" <l.s.r@web.de>]

Am 06.11.22 um 14:28 schrieb Ævar Arnfjörð Bjarmason:
>
> No, I think that:
>
> 1) J.5.7 does that on its own for C99

An extension is not part of the standard, by definition.  Section J is
informative, not normative.  J.5.7 just says that there are systems out
there which allow casts from function pointers to object pointers and/or
back, which is not portable.

> 2) POSIX has orthagonally mandated this, seperate from C99.

It only requires dlsym(3) to work.  That's a narrow case.  A conforming
implementation could have function pointers wider than object pointers,
making conversions in the other direction lossy.  Or have function
pointers narrower than object pointers and let dlopen(3) place symbols
only in the range addressable by those.

> In practice I think it's always worked for dlsym(), but there's
> interesting changes in wording between v6 and v7 of POSIX:
>
>    - https://pubs.opengroup.org/onlinepubs/009695399/functions/dlsym.html
>    - https://pubs.opengroup.org/onlinepubs/9699919799/functions/dlsym.html
>
> v6 claims that conforming C compilers are required to produce a warning
> if this isn't supported (I haven't found the part of the standard
> they're referencing), and notes that the behavior may be deprecated in
> the future.
>
> Whereas v7 says that POSIX "requires this conversion to work correctly
> on conforming implementations".

From the second link: "The dlsym() function is moved from the XSI option
to the Base."  So dynamic libraries are no longer optional on POSIX
systems.  That means you can use dlsym(3) on any compliant system.  You
can also safely store its return value in an intptr_t IIUC.  But that
doesn't generalize to all function pointers.

> I think it's useful in itself to see what subset or superset of C we
> actually need to concern ourselves with.
>
> E.g. we have plenty of code that assumes ASCII, instead of catering to
> EBCDIC, and assuming NULL is (void *)0, not (void *)123456 or whatever.

NULL is defined as "0" or "(void *)0" by C99 6.3.2.3 Pointers paragraph
3 and 7.17 Common definitions <stddef.h> paragraph 3.

> Yes, in this case the alternative is trivial, but perhaps we'd find a
> use-case in the future.
>
> All I'm saying is let's leave the current one in place, as there's no
> indication that it's not supported by our targets.

Leaving undefined behavior in the code in the hope that we may come up
with a compelling use case for it later is a bad idea.  I really hope
we never find one.

René