On Thu, 21 Mar 2019 at 12:07, Jakub Jelinek <jakub@xxxxxxxxxx> wrote: [..] > Like what exactly? E.g. all the -Wformat-security warnings are about cases > where the format strings are constructed shortly before they are passed to > the format attribute functions, either unmodified or through gettext. KISS principle .. Maybe it is time to remove gettext support from gcc/binutils it is really so hard to maintain? Who needs this? I'm not trying to give any answers on those questions but people like you who are directly maintaining gcc should be able to balance between some priorities like what is most important and what is only decoration on the Christmas Tree. People are writing the code with i18n support which compiles without single warning. This is not a rocket science. I can understand that it may be difficult for some people but not everything needs to be done by single person. Isn't it? Just try to execute "update-po" target in gcc/ and you will see that only by this single command is possible to reduce gcc/po/ directory content by ~2MB (which is about 5% and that is only in one directory with translations) which says that for quite long time no one cares that most of the translations are not up-to-date. Maybe telling other people that if all compile time warnings related to gettex will be not sorted out before final gcc 9 i18n support will be dropped? Let's see how many people cares about that support (?). Chess players sometimes says that in this game more dangerous than chess mat is knowing that in next move you will be under pressure of that state. Every source code maintainer doesn't need to do everything and I'm not asking you why all those problems are or sort out every even minor issue. At least such person needs take care of some problem management by identify the problem and making aware of them people around, and assigning priority to each point of the list problems. It is really good to resent some statistics on each release. Statistics about up-to-date i18n or number of stats about warnings are only two I'm sure that you Am I could be right or not? Going back to main subject about default compile options. I have question for you Jakub :) Quote from redhat-rpm-config package buildflags.md: * `-fexceptions`: Provide exception unwinding support for C programs. See the [`-fexceptions` option in the GCC manual](https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#index-fexceptions) and the [`cleanup` variable attribute](https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html#index-cleanup-variable-attribute). This also hardens cancellation handling in C programs because it is not required to use an on-stack jump buffer to install a cancellation handler with `pthread_cleanup_push`. It also makes it possible to unwind the stack (using C++ `throw` or Rust panics) from C callback functions if a C library supports non-local exits from them (e.g., via `longjmp`). Is it still correct? If it is why that kind of issues are solved that way? Someone maybe remember in which one project this caused some issue? Building all code with exceptions when many people spent many hours to have code which does not uses exceptions is kind waste .. and still compile many programs with exceptions only causes that executable code is puffier. As you know even gcc is not compliant with above :) What about use -fno-rtti if it is possible to use it? kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
