> I could propose pointer, size functions but the
> entire C committee will likely balk at such functions and throw them out
> the window.
>
> They tried before in the Annex functions, and they crafted the horrible
> "rsize" functions that had implementation-defined limits on the number
> of characters you could possibly convert. This ended up resulting in
> RSIZE_MAX turning out to be something ridiculously tiny on certain
> machines, and surprising developers who tried to use it by serving as
> fun little DDoS points on certain platforms when text buffers exceeded
> the suddenly tiny RSIZE_MAX constant. We can argue that RSIZE_MAX was an
> incredibly silly function specification to address potential overflow
> concerns to begin with, but I don't think that's going to make [ptr,
> size] overloads compatible with std::span sail through the C any easier.
>
> That being said, maybe the C Committee can be talked into allowing sized
> overloads, but that's another 2x string functions to propose...

That was a former iteration of the C committee.

If you presented a modified C compiler with reasonably designed built-in
string object to the current C committee, I think you'd have a very high
chance of success. Everybody recognises that strings need doing right,
and a native built-in object is widely seen as the correct approach.
Here are some tiny C compilers to modify:

https://bellard.org/tcc/
https://github.com/rui314/8cc

C++ could sorely do with a native string object as well, so this would
be a very high impact project to embark upon.

Personally I would not present an owning-string design to WG14. I'd
choose a borrowed-view string design i.e. C code does the malloc() et
al, binds a string object to that, and then passes around string objects
which refer to storage elsewhere. That gets you out of many tricky
problems wrt how best to do dynamic memory management.

Later on down the line, one could then propose owning strings as an
extension. But I personally would not attempt that proposal first.

Niall