From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26200 invoked by alias); 11 Jul 2013 16:48:21 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 26162 invoked by uid 89); 11 Jul 2013 16:48:16 -0000 X-Spam-SWARE-Status: No, score=-5.5 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.1 Received: from ausxipps301.us.dell.com (HELO ausxipps301.us.dell.com) (143.166.148.223) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Thu, 11 Jul 2013 16:48:15 +0000 X-LoopCount0: from 10.175.216.249 From: To: CC: Subject: Re: [PATCH] Don't call strchr with the NULL character. Date: Thu, 11 Jul 2013 16:48:00 -0000 Message-ID: References: <51DEDA0E.8020809@broadcom.com> In-Reply-To: <51DEDA0E.8020809@broadcom.com> Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SW-Source: 2013-07/txt/msg00327.txt.bz2 On Jul 11, 2013, at 12:15 PM, Andrew Burgess wrote: > In the printf code we call strchr without guarding against the > case where the second parameter is NULL. >=20 > My local manpage for strchr doesn't say what happens in this case, > but this file: src/libiberty/strchr.c > suggests the results are undefined, and indeed, the answer I see is > not NULL (which is what I might have hoped for). The BSD manpage (for example on Mac OS) says: The strchr() function locates the first occurrence of c (converted to a char) in the string pointed to by s. The terminating null character is considered to be part of the string; therefore if c is `\0', the func- tions locate the terminating `\0'. It looks like libiberty/strchr.c does the same thing. It doesn't look unde= fined at all.=20 paul