On Thu, Mar 21, 2019 at 03:19:48PM +0000, Tomasz Kłoczko wrote:
On Thu, 21 Mar 2019 at 12:07, Jakub Jelinek <jakub(a)redhat.com>
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.
Maybe it is time to remove gettext support from gcc/binutils it is
really so hard to maintain?
i18n and l10n is an important goal of the upstream project.
It is not hard to maintain and I didn't say above the problem is caused
by gettext, if I have error ("jump to label %qD", label); then there
will not be any -Wformat-security warnings about it, the attributes
on gettext functions take care of everything.
The thing is that no -Wformat-security warnings on gcc source is not a
goal of the upstream project, because none of the cases actually take
user-controllable input, but there are many cases where some code sets
some const char * variable/field/whatever to say
G_("whatever %<something%>") and similar, those can't be printed with
%s in whatever code 5 frames up in the stack trace finally emits
in diagnostics, because we do want % processing in those strings.
If we in Fedora made -Werror=format-security warning default, then
one couldn't out of box build gcc nor many other projects. Not to mention
that it is extremely nasty, because if e.g. some project uses -Wno-format
for selected source(s), then if -Werror=format-security is the default
(or just present in flags), then it causes errors as well.
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.
The translations are provided to gcc by a different project -
translationproject.org - some translations are in very good shape, others
are lacking, but that doesn't mean translations aren't useful.
gcc has around 13000 translatable messages and quite a lot of that changes
from release to release.
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-fe...
and the [`cleanup` variable
attribute](https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.....
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?
This is to make sure pthread_cancel works properly, as the comment says.
-fasynchronous-unwind-tables is the default (upstream default; on most
targets Fedora cares about, otherwise added by %optflags anyway) and that is
desirable to be able to debug properly, as well as for pthread_cancel,
backtrace etc. -fexceptions for C code doesn't really change pretty much
anything for most of the code, all it changes is how __attribute__((cleanup
(...))) behaves and tells glibc headers to use that attribute for
pthread_cleanup*.
So, I don't really understand your objection to -fexceptions for C code,
it just changes cases where it is actually highly desirable that it works
that way for pthread_cancel, C++ exception compatibility etc.
And for C++ it is the default.
Of course if you have some package that you know will not use exceptions,
nor pthread_cancel etc., you can build with -fno-exceptions -fno-rtti,
as I said for C it will not really make a difference, for C++ surely will.
A more difficult question is if you have a library, because then it is not
just about whether the library itself uses exceptions/pthread_cancel etc.,
but also whether any users of that library use those.
Jakub