Date: Fri, 02 Dec 2016 21:38:19 -0800 From: Ravi Pokala <rpokala@mac.com> To: Kyle Evans <kevans91@ksu.edu>, "Kenneth D. Merry" <ken@freebsd.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r309374 - in head: sbin/camcontrol sys/cam/scsi Message-ID: <F2FD52F5-E537-456E-B741-6F4E4FE280F5@panasas.com> In-Reply-To: <CACNAnaHaP3esEcudefF3JvtBt5Mv2Kkyo8eRpQXd_EzBD3TvdQ@mail.gmail.com> References: <201612012220.uB1MKSbR054941@repo.freebsd.org> <CACNAnaHaP3esEcudefF3JvtBt5Mv2Kkyo8eRpQXd_EzBD3TvdQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
-----Original Message-----
> From: <owner-src-committers@freebsd.org> on behalf of Kyle Evans <kevans91@ksu.edu>
> Date: 2016-12-02, Friday at 20:44
> To: "Kenneth D. Merry" <ken@freebsd.org>
> Cc: <src-committers@freebsd.org>, <svn-src-all@freebsd.org>, <svn-src-head@freebsd.org>
> 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'. <shrug>
-Ravi (rpokala@)
> Thanks,
>
> Kyle Evans
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F2FD52F5-E537-456E-B741-6F4E4FE280F5>