From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 515 invoked by alias); 17 Nov 2010 11:50:26 -0000 Received: (qmail 506 invoked by uid 22791); 17 Nov 2010 11:50:25 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,TW_CP X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 17 Nov 2010 11:50:19 +0000 From: "joseph at codesourcery dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/46513] Request: Warning for use of unsafe string handling functions X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: joseph at codesourcery dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Wed, 17 Nov 2010 11:51:00 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2010-11/txt/msg02189.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46513 --- Comment #6 from joseph at codesourcery dot com 2010-11-17 11:50:16 UTC --- On Wed, 17 Nov 2010, noloader at gmail dot com wrote: > I stand corrected: C1X draft dated 2010-10-04 now includes the bounds checking > interfaces. See "C1X Draft", > http://www.open-std.org/Jtc1/sc22/wg14/www/docs/n1516.pdf at > http://www.open-std.org/Jtc1/sc22/wg14/www/projects. > > So in addition to [nearly ubiquitous] support for strlcpy and friends, we will > have strcpy_s and friends. I can't imagine glibc will want to have that set of functions in libc - I expect it will simply omit that optional set of interfaces and not define __STDC_LIB_EXT1__. Maybe someone will write a glibc add-on putting them in a separate library that a handful of people might then use. *Some* of the functions there are useful, but the notion that tmpfile (for example) has security issues requiring tmpfile_s is nonsense. And the main utility of most of those functions is to retrofit security improvements to old code without understanding it. glibc has its own means for such retrofitting (in particular _FORTIFY_SOURCE). In both cases they are really a matter of reducing the risk from certain kinds of bugs rather than fixing them; to fix them, you need actually to understand the code and determine when you should avoid arbitrary limits and allocate as much memory as needed (taking care about overflow when calculating allocation sizes) and when you should impose limits and how you should handle overflow of them (quietly truncating is not generally a good approach); safer interfaces and _FORTIFY_SOURCE should then be used *on top of* proper design and calculation of allocations, to reduce the risk of any remaining bugs, rather than as a substitute for avoiding the possibility of overflow or truncation in the first place. If you wish to enforce a coding standard disallowing certain functions in a particular code base, you are free to use existing GCC features such as "#pragma GCC poison" and the "deprecated" attribute. That seems better to me than GCC embedding particular assumptions about a particular set of functions, when everyone will have their own preferences about what functions should be used and whether functions are safe in a given code base depends on how it uses them.