On Thu, Sep 24, 2015 at 06:55:11PM +0200, Bernd Schmidt wrote: > 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 can believe its an odd way to write C, but is it actually a bad one? I expect if I got warnings for code like that I'd be pretty unhappy about either moving the constant out where the compiler can't always see it, or making it a macro. > >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++. existing practice is certainly important, but I would say that what is good practice is also very important. It seems to me that warning for these constants is basically making it hard to follow a better practice than the existing one. That seems pretty unfortunate. On the other hand I've become much more of a C++ programmer than a C one so, I'm probably not the best judge. Trev > > > Bernd
