Re: [musl] C23 implications for C libraries

[Rich Felker <dalias@libc.org>]

On Fri, May 05, 2023 at 08:56:41AM +0200, Jₑₙₛ Gustedt wrote:
> Hello,
> 
> on Thu, 4 May 2023 20:37:58 -0400 you (JeanHeyd Meneide
> <phdofthehouse@gmail.com>) wrote:
> 
> > > for example, stuff like the %B specifier are technically optional
> > > given  
> > that the uppercase conversion specifier namespace wasn't reserved,
> > but iirc there's no known implementation of C that uses it for any >
> > other purpose.
> > 
> >      There was apparently one implementation that was already using
> > %B as a kind of numeric printout (not for binary) that was reported
> > during the meeting and at a few other junctures, so unfortunately it
> > might not be fully portable. …
> 
> Yes, in general I am always amazed to see how diversive and inventive
> C implementations are. So changing things even as innocent sounding
> like a format specifier or adding new function identifiers that could
> be conflicting with applications is usually watched very
> closely. There are really a lot of C implementations out there, and
> in general they use the design space that is offered to them.
> 
> For format specifiers this is even more complicated. There are C
> libraries that provide interfaces to add such specifiers from user
> space. So here the risk for conflicts can not easily be assessed by
> WG14 (we don't have the data). So it should be left to the C library
> implementors to assess this risk.

FWIW, from the musl side, my assessment of this risk is that it makes
no sense at all. The features you get are accessible only with
hard-coded knowledge of your implementation; they aren't even
detectable via probing. And unless you're a behemoth with effective
veto power, there's always a risk that future official or de facto
standards will impose conflicting requirements for whatever you
assigned a custom meaning to.

Rich