From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2645 invoked by alias); 14 Aug 2014 01:01:31 -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 2628 invoked by uid 89); 14 Aug 2014 01:01:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 X-HELO: smtp.stanford.edu From: Russ Allbery To: Subject: Re: Implement C11 annex K? In-Reply-To: (Joseph S. Myers's message of "Thu, 14 Aug 2014 00:55:42 +0000") References: <53EBD7D9.1040008@cs.ucla.edu> <20140813213520.GQ12888@brightrain.aerifal.cx> <53EBEACD.3070000@googlemail.com> <87k36cc559.fsf@windlord.stanford.edu> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Date: Thu, 14 Aug 2014 01:01:00 -0000 Message-ID: <87bnrndgv0.fsf@windlord.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2014-08/txt/msg00219.txt.bz2 "Joseph S. Myers" writes: > On Wed, 13 Aug 2014, Russ Allbery wrote: >> If the answer is "use strcpy and strcat because this code is provably >> correct with them," I guess I understand your position, but if I somehow > stpcpy is better than strcpy and strcat here; repeated strcat, or strlcat > as in your code, has quadratic overhead repeatedly looking for the end of > the string being built up, whereas stpcpy returns the end pointer for use > in the next stpcpy call. Arguably, yes, but the code is not performance-critical, and I find the stpcpy code (slightly) harder to read, possibly just because it's less familiar. No one is ever going to notice that quadratic factor here. Either way, though, I would prefer the belt and suspenders of the additional check on the length calculation logic. >> messed up the length calculation logic, I would prefer to truncate the > It's not obvious what a safer version of the stpcpy code would look > like, and the length calculation logic fails to allow for the sum of the > lengths exceeding SIZE_MAX (e.g. from a long separator, or from several > pointers to the same long string in the vector) (so resulting in buffer > overflows from any version that doesn't check each write fits in the > remaining space). (This size calculation as written could feasibly > overflow even on a 64-bit system; many such overflows are only realistic > on 32-bit systems.) Yes, thank you, that's a good point. I need to fix that. But I think that's orthogonal to the strlcpy vs. strcpy/stpcpy debate here. One has to do the size calculation in roughly the same way with either approach, and the overflow check applies to either approach, I believe. -- Russ Allbery (eagle@eyrie.org)