public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/61372] Add warning to detect noexcept functions that might throw
       [not found] <bug-61372-4@http.gcc.gnu.org/bugzilla/>
@ 2020-08-16 10:46 ` dcrocker at eschertech dot com
  2020-08-17  9:42 ` redi at gcc dot gnu.org
                   ` (7 subsequent siblings)
  8 siblings, 0 replies; 9+ messages in thread
From: dcrocker at eschertech dot com @ 2020-08-16 10:46 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61372

David Crocker <dcrocker at eschertech dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dcrocker at eschertech dot com

--- Comment #1 from David Crocker <dcrocker at eschertech dot com> ---
I too would find this very useful. However, it's essential that functions
declared 'extern "C" ' are (or optionally can be) assumed to not throw
exceptions. Otherwise, calls to C library functions and MCU vendor-supplied C
header files from C++ functions declared 'noexcept' will trigger this warning.
Also, the warning should be disabled when -fno-exceptions is used.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug c++/61372] Add warning to detect noexcept functions that might throw
       [not found] <bug-61372-4@http.gcc.gnu.org/bugzilla/>
  2020-08-16 10:46 ` [Bug c++/61372] Add warning to detect noexcept functions that might throw dcrocker at eschertech dot com
@ 2020-08-17  9:42 ` redi at gcc dot gnu.org
  2020-08-18 14:03 ` dcrocker at eschertech dot com
                   ` (6 subsequent siblings)
  8 siblings, 0 replies; 9+ messages in thread
From: redi at gcc dot gnu.org @ 2020-08-17  9:42 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61372

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic
             Blocks|                            |87403

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
extern "C" functions can throw, so it would be wrong to unconditionally assume
they can't.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403
[Bug 87403] [Meta-bug] Issues that suggest a new warning

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug c++/61372] Add warning to detect noexcept functions that might throw
       [not found] <bug-61372-4@http.gcc.gnu.org/bugzilla/>
  2020-08-16 10:46 ` [Bug c++/61372] Add warning to detect noexcept functions that might throw dcrocker at eschertech dot com
  2020-08-17  9:42 ` redi at gcc dot gnu.org
@ 2020-08-18 14:03 ` dcrocker at eschertech dot com
  2020-08-18 14:46 ` redi at gcc dot gnu.org
                   ` (5 subsequent siblings)
  8 siblings, 0 replies; 9+ messages in thread
From: dcrocker at eschertech dot com @ 2020-08-18 14:03 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61372

--- Comment #3 from David Crocker <dcrocker at eschertech dot com> ---
(In reply to Jonathan Wakely from comment #2)
> extern "C" functions can throw, so it would be wrong to unconditionally
> assume they can't.

True, you can write an extern "C" function that throws. But does it ever make
sense to? I don't think so. Functions written in C and then declared extern "C"
in a C++ program so that they can be called from C++ won't throw or propagate
exceptions, even if they end up calling functions written in C++ that throw.
The only reason to write a function in C++ and declare it extern "C" is so that
it call be called from C, in which case it had better not throw.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug c++/61372] Add warning to detect noexcept functions that might throw
       [not found] <bug-61372-4@http.gcc.gnu.org/bugzilla/>
                   ` (2 preceding siblings ...)
  2020-08-18 14:03 ` dcrocker at eschertech dot com
@ 2020-08-18 14:46 ` redi at gcc dot gnu.org
  2020-08-19 14:05 ` dcrocker at eschertech dot com
                   ` (4 subsequent siblings)
  8 siblings, 0 replies; 9+ messages in thread
From: redi at gcc dot gnu.org @ 2020-08-18 14:46 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61372

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to David Crocker from comment #3)
> (In reply to Jonathan Wakely from comment #2)
> > extern "C" functions can throw, so it would be wrong to unconditionally
> > assume they can't.
> 
> True, you can write an extern "C" function that throws. But does it ever
> make sense to? I don't think so. Functions written in C and then declared
> extern "C" in a C++ program so that they can be called from C++ won't throw
> or propagate exceptions,

That's not true. std::bsearch and std::qsort are counterexamples. You don't
know what the user-provided function does, and you can't assume it doesn't
throw.

> even if they end up calling functions written in
> C++ that throw. The only reason to write a function in C++ and declare it
> extern "C" is so that it call be called from C, in which case it had better
> not throw.

That's an incorrect assumption. Not all extern "C" functions are written in
C++. Even if they are, you can't assume they don't throw because they could use
callbacks that can throw, or they might throw even in C programs (which works
fine for some targets, unwinding the stack exactly as a C++ program wants it
to).

It would be OK to optionally assume functions with C language linkage don't
throw, but it must be optional.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug c++/61372] Add warning to detect noexcept functions that might throw
       [not found] <bug-61372-4@http.gcc.gnu.org/bugzilla/>
                   ` (3 preceding siblings ...)
  2020-08-18 14:46 ` redi at gcc dot gnu.org
@ 2020-08-19 14:05 ` dcrocker at eschertech dot com
  2020-08-19 14:24 ` redi at gcc dot gnu.org
                   ` (3 subsequent siblings)
  8 siblings, 0 replies; 9+ messages in thread
From: dcrocker at eschertech dot com @ 2020-08-19 14:05 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61372

--- Comment #5 from David Crocker <dcrocker at eschertech dot com> ---
You seem to be assuming that C++ exceptions can propagate through functions
compiled with a C compiler. On most platforms, they normally cannot, because a
C compiler does not produce the information needed for the C++ unwind mechanism
to unwind the call stack. If you want bsearch and qsort to propagate C++
exceptions, on most platforms the implementations of those functions would have
to be compiled either using a C++ compiler, or with a C compiler using a
special option that tells the compiler to include the tables and/or code needed
to propagate C++ exceptions. Otherwise the exception will end up at
std::unexpected. Maybe bsearch and qsort in newlib are compiled this way, I
haven't checked.

I don't care whether extern "C" functions are to be assumed noexcept by default
or another compiler option is needed to specify that. But without this
facility, the proposed warning will be useless in practice, at least for people
like me writing embedded software.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug c++/61372] Add warning to detect noexcept functions that might throw
       [not found] <bug-61372-4@http.gcc.gnu.org/bugzilla/>
                   ` (4 preceding siblings ...)
  2020-08-19 14:05 ` dcrocker at eschertech dot com
@ 2020-08-19 14:24 ` redi at gcc dot gnu.org
  2020-08-24 20:11 ` pinskia at gcc dot gnu.org
                   ` (2 subsequent siblings)
  8 siblings, 0 replies; 9+ messages in thread
From: redi at gcc dot gnu.org @ 2020-08-19 14:24 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61372

--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to David Crocker from comment #5)
> You seem to be assuming that C++ exceptions can propagate through functions
> compiled with a C compiler.

I'm not assuming anything. I know for a fact that they can do so on some
platforms.

It is provably incorrect to say that extern "C" functions can't exit via an
exception. So it would be wrong to add a new warning which unconditionally
assumes extern "C" functions never throw.

> On most platforms, they normally cannot, because

Define most.

GCC supports it by default on many platforms.

> a C compiler does not produce the information needed for the C++ unwind
> mechanism to unwind the call stack. If you want bsearch and qsort to
> propagate C++ exceptions, on most platforms the implementations of those
> functions would have to be compiled either using a C++ compiler, or with a C
> compiler using a special option that tells the compiler to include the
> tables and/or code needed to propagate C++ exceptions. Otherwise the
> exception will end up at std::unexpected. Maybe bsearch and qsort in newlib
> are compiled this way, I haven't checked.

What has newlib got to do with anything? Are you asking for a new option that
only works when using newlib? Don't assume your use case is universal. New GCC
options need to consider a broad range of uses.

> I don't care whether extern "C" functions are to be assumed noexcept by
> default or another compiler option is needed to specify that. But without
> this facility, the proposed warning will be useless in practice, at least
> for people like me writing embedded software.

OK, so why do you keep arguing about it? What I said is it that treating extern
"C" functions as non-throwing needs to be optional. You've repeatedly argued
that my reasoning for that is bogus, based on "does it ever make sense to?" and
the answer is yes, sometimes it does.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug c++/61372] Add warning to detect noexcept functions that might throw
       [not found] <bug-61372-4@http.gcc.gnu.org/bugzilla/>
                   ` (5 preceding siblings ...)
  2020-08-19 14:24 ` redi at gcc dot gnu.org
@ 2020-08-24 20:11 ` pinskia at gcc dot gnu.org
  2021-10-27  5:11 ` [Bug c++/61372] Add warning to detect noexcept functions that might throw [-Wnoexcept-mismatch] egallager at gcc dot gnu.org
  2021-10-27  5:17 ` egallager at gcc dot gnu.org
  8 siblings, 0 replies; 9+ messages in thread
From: pinskia at gcc dot gnu.org @ 2020-08-24 20:11 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61372

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #2)
> extern "C" functions can throw, so it would be wrong to unconditionally
> assume they can't.

Yes that is correct.  Even extern "C" functions could be written in C++ to
provide an interface from C to C++ code.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug c++/61372] Add warning to detect noexcept functions that might throw [-Wnoexcept-mismatch]
       [not found] <bug-61372-4@http.gcc.gnu.org/bugzilla/>
                   ` (6 preceding siblings ...)
  2020-08-24 20:11 ` pinskia at gcc dot gnu.org
@ 2021-10-27  5:11 ` egallager at gcc dot gnu.org
  2021-10-27  5:17 ` egallager at gcc dot gnu.org
  8 siblings, 0 replies; 9+ messages in thread
From: egallager at gcc dot gnu.org @ 2021-10-27  5:11 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61372

Eric Gallager <egallager at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |egallager at gcc dot gnu.org
            Summary|Add warning to detect       |Add warning to detect
                   |noexcept functions that     |noexcept functions that
                   |might throw                 |might throw
                   |                            |[-Wnoexcept-mismatch]

--- Comment #8 from Eric Gallager <egallager at gcc dot gnu.org> ---
retitling to include proposed warning flag name in title

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug c++/61372] Add warning to detect noexcept functions that might throw [-Wnoexcept-mismatch]
       [not found] <bug-61372-4@http.gcc.gnu.org/bugzilla/>
                   ` (7 preceding siblings ...)
  2021-10-27  5:11 ` [Bug c++/61372] Add warning to detect noexcept functions that might throw [-Wnoexcept-mismatch] egallager at gcc dot gnu.org
@ 2021-10-27  5:17 ` egallager at gcc dot gnu.org
  8 siblings, 0 replies; 9+ messages in thread
From: egallager at gcc dot gnu.org @ 2021-10-27  5:17 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61372

Eric Gallager <egallager at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rafael at espindo dot la

--- Comment #9 from Eric Gallager <egallager at gcc dot gnu.org> ---
*** Bug 94112 has been marked as a duplicate of this bug. ***

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2021-10-27  5:17 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <bug-61372-4@http.gcc.gnu.org/bugzilla/>
2020-08-16 10:46 ` [Bug c++/61372] Add warning to detect noexcept functions that might throw dcrocker at eschertech dot com
2020-08-17  9:42 ` redi at gcc dot gnu.org
2020-08-18 14:03 ` dcrocker at eschertech dot com
2020-08-18 14:46 ` redi at gcc dot gnu.org
2020-08-19 14:05 ` dcrocker at eschertech dot com
2020-08-19 14:24 ` redi at gcc dot gnu.org
2020-08-24 20:11 ` pinskia at gcc dot gnu.org
2021-10-27  5:11 ` [Bug c++/61372] Add warning to detect noexcept functions that might throw [-Wnoexcept-mismatch] egallager at gcc dot gnu.org
2021-10-27  5:17 ` egallager at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).