From owner-svn-src-head@freebsd.org Sat Dec 3 05:38:45 2016 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A2A87C648EF; Sat, 3 Dec 2016 05:38:45 +0000 (UTC) (envelope-from rpokala@mac.com) Received: from mr11p00im-asmtp004.me.com (mr11p00im-asmtp004.me.com [17.110.69.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 86F35AB1; Sat, 3 Dec 2016 05:38:45 +0000 (UTC) (envelope-from rpokala@mac.com) Received: from process-dkim-sign-daemon.mr11p00im-asmtp004.me.com by mr11p00im-asmtp004.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0OHL00A00GVXHA00@mr11p00im-asmtp004.me.com>; Sat, 03 Dec 2016 05:38:23 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mac.com; s=4d515a; t=1480743503; bh=3Ob/M+uh5pIJ/jfWk1Ttzkuu1cFkPcBZvWK1Za5sk4E=; h=Date:Subject:From:To:Message-id:MIME-version:Content-type; b=uugDXZ983mPgfv2Hu3AgKOiuW3fY03k4zeBhzjfRhm1TL222tdMaYOAkr9dN7sH1h O4dvEv8+JJJsxp/2jtdTZpuW/gAIglFtv9BQmTuY/Vmncc31ALHXOoHnrH6/EhZ7Ws /FckjL4jwGRab8B4GraxVQcL3UmdI26dRuJwFvMjyTrfKYCuZDzojnYX9QZiO2MzF1 QbtO7DKHbW8HA7m6lxh5DJGJjzjZ5Kh3A0/yRlsWxefQsdePool2g5ddqNqJaKk8t9 d0IbMxY0rq3F40kzNoOUR1oVJC32VVf+sLOQWm3LTl8xKSOjTXqlAFsPc5dY6sUjHq jlGFn6Pn0/p2Q== Received: from [192.168.1.4] (c-67-188-225-23.hsd1.ca.comcast.net [67.188.225.23]) by mr11p00im-asmtp004.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0OHL00EKOGZXBB30@mr11p00im-asmtp004.me.com>; Sat, 03 Dec 2016 05:38:23 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-12-03_04:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603290000 definitions=main-1612030099 User-Agent: Microsoft-MacOutlook/f.1c.1.161117 Date: Fri, 02 Dec 2016 21:38:19 -0800 Subject: Re: svn commit: r309374 - in head: sbin/camcontrol sys/cam/scsi From: Ravi Pokala Sender: "Pokala, Ravi" To: Kyle Evans , "Kenneth D. Merry" Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Message-id: Thread-topic: svn commit: r309374 - in head: sbin/camcontrol sys/cam/scsi References: <201612012220.uB1MKSbR054941@repo.freebsd.org> In-reply-to: MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7bit X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2016 05:38:45 -0000 -----Original Message----- > From: on behalf of Kyle Evans > Date: 2016-12-02, Friday at 20:44 > To: "Kenneth D. Merry" > Cc: , , > Subject: Re: svn commit: r309374 - in head: sbin/camcontrol sys/cam/scsi > >> [...] >> + >> + if (action == TIMESTAMP_REPORT) { >> + error = report_timestamp(device, &ts, retry_count, >> + timeout); >> + if (error != 0) { >> + goto bailout; >> + } else if (strcmp(format_string, MIL) == 0) { >> + printf("Timestamp in milliseconds: %ju\n", >> + (uintmax_t)ts); >> + } else { >> + char temp_timestamp_string[100]; >> + time_t time_var = ts / 1000; > > Hi, > > FWIW: Building -CURRENT on mips.mips (w/ freebsd-wifi-build), > mips-gcc gets upset at the above line with the following error: > > /wifi-build/src/sbin/camcontrol/timestamp.c: In function 'timestamp': > /wifi-build/src/sbin/camcontrol/timestamp.c:459:25: error: 'ts' may be > used uninitialized in this function [-Werror=maybe-uninitialized] > time_t time_var = ts / 1000; Interesting. I just did a tinderbox build earlier this evening, and this wasn't reported. > I understand that this is a bogus error because at this point it > pretty much *has* to be set by the report_timestamp call just prior, > but is there a clean way to trick GCC into agreeing, or is it just a > matter of explicitly initializing it to 0 before the report_timestamp > call? Actually, it's a valid warning. While all paths to that point in timestamp() go through report_timestamp(), not all paths through report_timestamp() set *ts. Specifically, if cam_getccb() or cam_send_ccb() fail, or the request was not completed, report_timestamp() does 'goto bailout' without setting *ts. I'm disappointed that `clang' (on i386 and amd64) didn't notice this; I was under the impression `clang' did more of that type of deep path analysis than `gcc'. -Ravi (rpokala@) > Thanks, > > Kyle Evans