On Thu, 2015-09-24 at 13:56 +0200, Bernd Schmidt wrote: > I think at this point we have reports of just two packages generating > extra warnings, with the warnings at least justifiable in both cases. So > my vote would be to leave things as-is for now and see if more reports > come in. It is after all expected that a new warning option generates > new warnings. > > > Bernd
At least one of the warnings in glibc is not justified (in my opinion). The header file timezone/private.h defines time_t_min and time_t_max. These are not used in any of the timezone files built by glibc but if you look at the complete tz package they are used when building other objects that are not part of the glibc tz component and that include private.h. I would make two arguments about why I don't think we should warn. One is that 'static int const foo = 1' seems a lot like '#define foo 1' and we don't complain about the macro foo not being used. If we complain about the unused const, why not complain about the unused macro? We don't complain because we know it would result in too many warnings in existing code. If we want people to move away from macros, and I think we do, then we should not make it harder to do so by introducing new warnings when they change. The other is that C++ does not complain about this. I know that C and C++ are different languages with different rules but it seems like this difference is a difference that doesn't have to exist. Either both should complain or neither should complain. I can't think of any valid reason for one to complain and the other not to. I think using the used attribute is probably a reasonable way to address this issue if we continue to generate the warning but I still feel it is a bad warning in that it will (sometimes) warn about a coding style that seems perfectly reasonable to me. Steve Ellcey sell...@imgtec.com
