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@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.
>
> 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-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?
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
_______________________________________________
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
