Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752545AbbEFPV2 (ORCPT ); Wed, 6 May 2015 11:21:28 -0400 Received: from mail-db3on0066.outbound.protection.outlook.com ([157.55.234.66]:43264 "EHLO emea01-db3-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752017AbbEFPVY (ORCPT ); Wed, 6 May 2015 11:21:24 -0400 Authentication-Results: vger.kernel.org; dkim=none (message not signed) header.d=none; Message-ID: <554A3161.3030609@ezchip.com> Date: Wed, 6 May 2015 11:21:05 -0400 From: Chris Metcalf User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Dan Carpenter CC: Linus Torvalds , Al Viro , Fabian Frederick , Randy Dunlap , Rickard Strandqvist , , Peter Zijlstra , "David S. Miller" , Frederic Weisbecker , Andrew Morton , Sam Ravnborg , Stephen Rothwell , "Theodore Ts'o" , Grant Likely , Linux Kernel Mailing List , Subject: Re: [PATCH 2/3] string: provide strscpy() and strscpy_truncate() References: <1430409677-13284-1-git-send-email-cmetcalf@ezchip.com> <1430409677-13284-3-git-send-email-cmetcalf@ezchip.com> <20150506150140.GB12986@mwanda> In-Reply-To: <20150506150140.GB12986@mwanda> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [173.76.21.154] X-ClientProxiedBy: BN1PR12CA0008.namprd12.prod.outlook.com (25.160.77.18) To HE1PR02MB0780.eurprd02.prod.outlook.com (25.161.118.144) X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR02MB0780; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(5005006)(3002001);SRVR:HE1PR02MB0780;BCL:0;PCL:0;RULEID:;SRVR:HE1PR02MB0780; X-Forefront-PRVS: 0568F32D91 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(6049001)(6009001)(479174004)(24454002)(377454003)(51704005)(59896002)(62966003)(117156001)(77156002)(15975445007)(122386002)(92566002)(40100003)(2950100001)(50466002)(77096005)(189998001)(42186005)(36756003)(46102003)(50986999)(87976001)(64126003)(4001350100001)(76176999)(65816999)(87266999)(54356999)(66066001)(65956001)(47776003)(5001960100002)(5001920100001)(110136002)(86362001)(83506001)(19580395003)(80316001)(23746002)(33656002)(18886065003);DIR:OUT;SFP:1101;SCL:1;SRVR:HE1PR02MB0780;H:[192.168.1.163];FPR:;SPF:None;MLV:sfv;LANG:en; X-OriginatorOrg: ezchip.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 May 2015 15:21:17.9161 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR02MB0780 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1538 Lines: 36 On 5/6/2015 11:01 AM, Dan Carpenter wrote: > On Thu, Apr 30, 2015 at 12:01:16PM -0400, Chris Metcalf wrote: >> >+ssize_t strscpy(char *dest, const char *src, size_t count) >> >+{ >> >+ ssize_t res = strscpy_truncate(dest, src, count); >> >+ if (res < 0 && count != 0) >> >+ dest[0] = '\0'; > How is this better than returning a truncated string? Is it just > because the caller was naughty so we give them a spanking? There are basically two issues here: 1. A truncated string with an error return may still cause program errors, even if the caller checks for the error return, if the buffer is later interpreted as a valid string due to some other program error. It's defensive programming. 2. Programmers are fond of ignoring error returns. My experience with truncated strings is that in too many cases, truncation causes program errors down the line. It's better to ensure that no partial string is returned in this case. In a perfect world, all error returns would be checked, and there would be no need for this, but we definitely don't live in that world :-) That said, although I think my approach is correct, I'm open to a consensus that having strscpy() leave a truncated string in the dest buffer is better. -- Chris Metcalf, EZChip Semiconductor http://www.ezchip.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/