Paul Eggert wrote: > > +# if __GLIBC__ >= 2 > > _GL_CXXALIASWARN (strtol); > > +# endif > > Would it make sense to move the __GLIBC__ >= 2 check into > _GL_CXXALIASWARN so that we needn't worry about making these sorts of > patches? How much benefit to non-glibc ports do we obtain from requiring > each _GL_CXXALIASWARN caller to decide whether to worry about __GLIBC__?
It would save us a a few patches occasionally. But it's only a minority of the C++ related compilation failures. Looking in the ChangeLog, C++ compilation failures have different causes: - _GL_CXXALIASWARN with undefined functions, - _GL_CXXALIASWARN with differences in 'restrict', - _GL_CXXALIASWARN with slightly different function signature, - exception specifications, - overloaded functions (w.r.t. 'const'), - linkage. Not all developers develop on glibc systems. Just read a comment by a user today [1]: "My phone runs Linux. My GF's phone runs Linux. My TV runs Linux, too. So does the TV box-set (cable provider), .... And I say this as a desktop OpenBSD user." So, unless it's really too much effort to keep most of these _GL_CXXALIASWARN invocations enabled almost everywhere, I'd like to keep them. Bruno [1] https://news.ycombinator.com/item?id=26451540
