On 09/24/2015 06:11 PM, Steve Ellcey wrote:
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.
The standard C way of writing this would be to declare time_t_min in the
header and have its definition in another file, or use a TIME_T_MIN
macro as glibc does in mktime.c. That file even has a local redefinition:
time_t time_t_min = TIME_T_MIN;
So at the very least the warning points at code that has some oddities.
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.
Well, they _are_ different languages, and handling of const is one place
where they differ. For example, C++ consts can be used in places where
constant expressions are required. The following is a valid C++ program
but not a C program:
const int v = 200;
int t[v];
The result is that the typical programming style for C is to have
constants #defined, while for C++ you can find more examples like the
above; I recall Stroustrup explicitly advocating that in the
introductory books I read 20 years ago, and using it as a selling point
for C++. Existing practice is important when deciding what to warn
about, and for the moment I remain convinced that C practice is
sufficiently different from C++.
Bernd
