On Thu, 2015-09-24 at 21:24 -0400, Trevor Saunders wrote: > 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
So, is there any consensus on this issue? I cannot build top-of-tree glibc with top-of-tree GCC due to this warning coming from timezone/private.h. If GCC is going to keep this warning then I should talk to the owners of the header file (tz group, not glibc) and see if they would be willing to add a unused attribute to it. Personally, I would rather have GCC not issue the warning, but that is just based on my opinion that the definition of a (possibly) unused static initialized variable in a C header is a reasonable practice. Steve Ellcey sell...@imgtec.com
