This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC][PATCH v2] Initial support for C11 Annex K Bounds checking functions
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Rich Felker <dalias at aerifal dot cx>
- Cc: Ulrich Bayer <ubayer at sba-research dot org>, <libc-alpha at sourceware dot org>
- Date: Thu, 6 Jun 2013 15:32:12 +0000
- Subject: Re: [RFC][PATCH v2] Initial support for C11 Annex K Bounds checking functions
- References: <5102DBFD dot 4060103 at sba-research dot org> <513DE7A1 dot 8080501 at sba-research dot org> <Pine dot LNX dot 4 dot 64 dot 1305151554100 dot 15900 at digraph dot polyomino dot org dot uk> <51AF6406 dot 30201 at sba-research dot org> <Pine dot LNX dot 4 dot 64 dot 1306051643310 dot 14749 at digraph dot polyomino dot org dot uk> <51B07F27 dot 2070401 at sba-research dot org> <20130606141530 dot GL29800 at brightrain dot aerifal dot cx>
On Thu, 6 Jun 2013, Rich Felker wrote:
> > I tend to agree. It's a pity we loose GCC's warnings about null pointer
> > arguments though. I don't like the fact that a program becomes more unsecure
> > by the fact that is uses the Annex K functions.
>
> I hardly find it a pity; rather, it's good reason for people NOT to
> use these ill-conceived functions and to instead simply compile proper
> portable C (portable in the sense of not depending on an optional
> annex) with _FORTIFY_SOURCE.
I think use of dynamic allocation functions such as those in TR 24731-2
(which didn't get merged into C11, unlike 24731-1 which became Annex K) is
perfectly reasonable. (Some of those functions were derived from glibc
via POSIX. As noted on the wiki todo list, the wide-character versions
aswprintf, vaswprintf, getwdelim, getwline aren't currently implemented in
glibc, but would be a good addition and shouldn't be that hard to add.
See <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1388.pdf> for the
final draft version I think is essentially the same as was published.)
> I'm unsure, but there's at lease one place that both the optimization
> and the warning would be unwanted: valid test code to check that the
> runtime-constraint violation handlers get called. I suppose it's also
There are various places glibc testcases get compiler warnings through
testing deprecated interfaces or _FORTIFY_SOURCE functionality; I don't
think that can be avoided (though we should try to stay clean of warnings
except where actually unavoidable).
--
Joseph S. Myers
joseph@codesourcery.com