This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Implement C11 annex K?
- From: Andreas Schwab <schwab at suse dot de>
- To: Rich Felker <dalias at libc dot org>
- Cc: Florian Weimer <fweimer at redhat dot com>, libc-alpha at sourceware dot org
- Date: Mon, 18 Aug 2014 09:31:21 +0200
- Subject: Re: Implement C11 annex K?
- Authentication-results: sourceware.org; auth=none
- References: <20140814022501 dot GT12888 at brightrain dot aerifal dot cx> <87r40jbq2p dot fsf at windlord dot stanford dot edu> <20140814054610 dot GV12888 at brightrain dot aerifal dot cx> <87ha1fbnrp dot fsf at windlord dot stanford dot edu> <53EC87A4 dot 1080805 at redhat dot com> <mvmr40j4cep dot fsf at hawking dot suse dot de> <53EC8A1F dot 8080203 at redhat dot com> <mvmmwb74bx0 dot fsf at hawking dot suse dot de> <20140814162628 dot GC12888 at brightrain dot aerifal dot cx> <87oavn57xc dot fsf at igel dot home> <20140814170422 dot GE12888 at brightrain dot aerifal dot cx>
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. The key point
is that the allocation size should be maintained as part of the string
type.
> 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.
Andreas.
--
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."