From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10347 invoked by alias); 13 Aug 2014 20:41:26 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 10335 invoked by uid 89); 13 Aug 2014 20:41:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00,RDNS_DYNAMIC,TVD_RCVD_IP autolearn=no version=3.3.2 X-HELO: brightrain.aerifal.cx Date: Wed, 13 Aug 2014 20:41:00 -0000 From: dalias To: "David A. Wheeler" Cc: libc-alpha Subject: Re: Implement C11 annex K? Message-ID: <20140813204118.GO12888@brightrain.aerifal.cx> References: <20140812234817.GG12888@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2014-08/txt/msg00207.txt.bz2 On Wed, Aug 13, 2014 at 03:23:29PM -0400, David A. Wheeler wrote: > On Tue, 12 Aug 2014 19:48:17 -0400, dalias wrote: > > I'd much rather see strlcpy/strlcat added. > > I'd be happy to have someone work to add strlcpy/strlcat, and > I'd be happy to focus on doing that *first*. > After all, strlcpy/strlcat are short, well-understood, and easy-to-use. > I see no need to put strlcpy/strlcat in a separate lib_s file, since they're short. > Annex K has other capabilities I'd like to see, and is a formal standard, but > staging work is fine. I suspect that strlcpy/strlcat could help in implementing strcpy_s > (I'd have to check to make sure). > > So... would a high-quality strlcpy/strlcat patch be (FINALLY!) accepted? I hope so, but I have no control over that other than speaking up in favor of it. > > > Portable application code can just set the handler, once. > > > > Not necessarily. There could already be library code and multiple > > threads running before entering main due to global ctors. > > Sure, but if the default is "no constraint handler set", then a constraint > handler won't be triggered by surprise. Yes, but portable code can't assume that. > > ... Library Y expects that the application using it > > setup the constraint handler, but the application is not the "user" of > > library Y; library X is the user. > > Hold it right there! A library that *requires* that a constraint handler be set is > already in a state of sin, because it's perfectly legal to set up the constraint > handler to return. You missed the point: that's the exact constraint handler it would _want_. But since the default is implementation-defined, it can't rely on that being there by default. Thus, it requires an explicit do-nothing constraint handler to be set. > I do understand that you have concerns about the constraint handlers. Got it. > Would it be better if there were GNU extensions for the Annex K functions > that guaranteed to *not* call the constraint handler ("NAME_s_e")? No, this would be yet another layer of utter crap functions on top of a layer of utter crap functions. There are many 3 or 4 "useful" functions out of the whole annex K (the main one being qsort_s) and the rest is just utterly redundant and not useful for the stated purpose (of making software more secure). And for some of them, implementing them imposes ugliness and potential bugs on other core functions unless you want completely redundant implementations -- for instance, the scanf core needs additional code to support the annex K scanf-family functions, specifically the ugly double-argument forms for %s, %c, and %[, and these are then incompatible with the POSIX i18n %N$ argument reordering. Rich