Re: Implement C11 annex K?

[Rich Felker <dalias at libc dot org>]

On Mon, Aug 18, 2014 at 09:31:21AM +0200, Andreas Schwab wrote:
> Rich Felker <dalias@libc.org> writes:
> 
> > I disagree strongly here. If you want that, you should be using a
> > language where it's idiomatic. Doing it in C just gets you the worst
> > of both worlds: (1) C's lack of syntax to express it concisely and
> > lack of exceptions to handle allocation failures, which are a horrible
> > pain to handle when they can happen at each operation rather than at
> > isolated resource-allocation points,
> 
> There is no need for exceptions.  Only need to add a flag to the string
> type that is set for an allocation failure (or if the buffer is full for
> static allocation) that can be tested at the end of a sequence of calls.
> Much like stdio's ferror, but without the stdio overhead.

Indeed. So why has nobody designed and pushed such a good API? All the
"secure string" libraries I've seen have been full of abort() calls or
simply dereference null pointers and crash...

> The key point
> is that the allocation size should be maintained as part of the string
> type.

If you use high-level string objects as inputs to your string
functions, this makes it impossible (or at least tricky) to use the
tail of a string, or an embedded substring of a string, in-place as
the argument to another function. On the other hand if the objects
always provide read-only access to the C string, and all functions
take C strings (and possibly also lengths for when you want to use
non-null-terminated input) as input, I think it works fine.

> > and (2) the HLL style loss of fail-safety (all operations can fail
> > because they do allocation under the hood), massive overhead in memory
> > usage and memory fragmentation, load on malloc/free, etc.
> 
> It is easy to also support static allocation, but with the failure flag
> as above the truncation can be detected reliably after the fact.

Yes.

Rich