Re: [PATCH 09/13] parse-options API: don't restrict OPT_SUBCOMMAND() to one *_fn type
- From
René Scharfe <l.s.r@web.de>
- Date
- Nov 12, 2022, 10:42 UTC
- Message-ID
- <36337a3f-6443-f272-09f0-7ddb3c20d7a4@web.de>
- In-Reply-To
- <221106.86k048w2f4.gmgdl@evledraar.gmail.com>
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.
Show 13 quoted lines
> 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.
Show 5 quoted lines
> 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.
Show 5 quoted lines
> 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é