|
From: Florian K. <fl...@ei...> - 2015-04-01 11:53:34
|
clang 3.6.0 says:
m_transtab.c:1548:42: warning: variable 'i' is uninitialized when used
here [-Wuninitialized]
for (EClassNo e = 0; e < ECLASS_N; i++) {
and it is right.. I suppose that was meant to read "e++" ?
clang's recommendation for a fix is quite funny;
m_transtab.c:1422:10: note: initialize the variable 'i' to silence this
warning
That recommendation is a manager's approach to fix compiler warnings :)
Come to think of it .. a really good warning here would have been: loop
does not iterate.
Florian
|
|
From: Philippe W. <phi...@sk...> - 2015-04-01 18:30:33
|
On Wed, 2015-04-01 at 13:53 +0200, Florian Krohm wrote:
> clang 3.6.0 says:
>
> m_transtab.c:1548:42: warning: variable 'i' is uninitialized when used
> here [-Wuninitialized]
> for (EClassNo e = 0; e < ECLASS_N; i++) {
>
> and it is right.. I suppose that was meant to read "e++" ?
Thanks for the bug report.
This causes an infinite loop when a sector is recycled.
Fixed in r15058.
I will update a regtest so that sector recycling is tested by
at least one test :(.
> clang's recommendation for a fix is quite funny;
>
> m_transtab.c:1422:10: note: initialize the variable 'i' to silence this
> warning
>
> That recommendation is a manager's approach to fix compiler warnings :)
Effectively, silence a warning is not the same as fixing a warning :).
But let's not criticise clang : warning well found.
(gcc usually finds this kind of things also IIRC, but not here ?).
>
> Come to think of it .. a really good warning here would have been: loop
> does not iterate.
I guess this implies to check the loop body to see if the loop variable
is modified or not.
Philippe
|
|
From: Florian K. <fl...@ei...> - 2015-04-01 19:07:14
|
On 01.04.2015 20:31, Philippe Waroquiers wrote: >> That recommendation is a manager's approach to fix compiler warnings :) > Effectively, silence a warning is not the same as fixing a warning :). My point! > (gcc usually finds this kind of things also IIRC, but not here ?). 4.8.2 and 4.9.2 did not report it. >> Come to think of it .. a really good warning here would have been: loop >> does not iterate. > I guess this implies to check the loop body to see if the loop variable > is modified or not. Yes. In general, that is undecidable. In this particular case, it'd have been elementary. Florian |