From: Tom Tromey <tom@tromey.com>
To: Pedro Alves <pedro@palves.net>
Cc: Kamil Rytarowski <kamil@netbsd.org>,
Simon Marchi <simark@simark.ca>,
gdb-patches@sourceware.org, tom@tromey.com
Subject: Re: [PATCH v2] gdb::handle_eintr, remove need to specify return type
Date: Fri, 16 Oct 2020 14:51:10 -0600 [thread overview]
Message-ID: <87a6wlopxd.fsf@tromey.com> (raw)
In-Reply-To: <223cf7ec-36b5-fe52-7d0f-e19c335be534@palves.net> (Pedro Alves's message of "Tue, 13 Oct 2020 15:17:00 +0100")
>>>>> "Pedro" == Pedro Alves <pedro@palves.net> writes:
Pedro> This eliminates the need to specify the return type when using
Pedro> handle_eintr. We let the compiler deduce it for us.
Thanks for doing this. This is closer to how I imagined this wrapper
being written.
Pedro> +template <typename ErrorValType,
Pedro> + typename Fun,
Pedro> + typename... Args>
Pedro> +inline auto
Pedro> +handle_eintr (ErrorValType errval, const Fun &f, const Args &... args)
Pedro> + -> decltype (f(args...))
It seems to me that errval and ErrorValType are unchanging properties of
the function being wrapped. And, normally they are -1 / int.
Also is there ever a case where the return type isn't the same as
ErrorValType?
So maybe instead of requiring these to all be redundantly specified, the
template could use a helper template class that specifies these things
(defaulting to the usual), and then one would write:
pid_t pid = gdb::handle_eintr<::waitpid> (...normal waitpid args);
I'm not sure it's really worth implementing this, but it's closer to
what I was picturing initially.
Tom
next prev parent reply other threads:[~2020-10-16 20:51 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-04 0:28 [PATCH v2 00/10] Add minimal NetBSD/amd64 gdbserver support Kamil Rytarowski
2020-09-04 0:28 ` [PATCH v2 01/10] Add handle_eintr to wrap EINTR handling in syscalls Kamil Rytarowski
2020-09-07 14:06 ` Simon Marchi
2020-09-07 14:59 ` Kamil Rytarowski
2020-10-12 17:56 ` [PATCH] gdb::handle_eintr, remove need to specify return type (Re: [PATCH v2 01/10] Add handle_eintr to wrap EINTR handling in syscalls) Pedro Alves
2020-10-13 13:43 ` Kamil Rytarowski
2020-10-13 14:17 ` [PATCH v2] gdb::handle_eintr, remove need to specify return type Pedro Alves
2020-10-13 14:54 ` Kamil Rytarowski
2020-10-16 20:51 ` Tom Tromey [this message]
2020-10-26 14:00 ` Pedro Alves
2020-10-26 14:20 ` Tom Tromey
2020-10-26 18:59 ` Pedro Alves
2020-09-04 0:28 ` [PATCH v2 02/10] Register a placeholder for NetBSD shared functions in gdb/nat Kamil Rytarowski
2020-09-07 18:44 ` Simon Marchi
2020-09-07 19:49 ` Kamil Rytarowski
2020-09-04 0:28 ` [PATCH v2 03/10] Build nat/netbsd-nat.o for the NetBSD native target Kamil Rytarowski
2020-09-04 0:28 ` [PATCH v2 04/10] Add netbsd_nat::pid_to_exec_file Kamil Rytarowski
2020-09-07 7:57 ` Andrew Burgess
2020-09-07 13:36 ` Kamil Rytarowski
2020-09-07 18:48 ` Simon Marchi
2020-09-07 18:47 ` Simon Marchi
2020-09-07 19:51 ` Kamil Rytarowski
2020-09-04 0:29 ` [PATCH v2 05/10] Add gdb/nat common functions for listing threads Kamil Rytarowski
2020-09-07 18:59 ` Simon Marchi
2020-09-07 19:57 ` Kamil Rytarowski
2020-09-04 0:29 ` [PATCH v2 06/10] Add netbsd_nat::enable_proc_events in gdb/nat Kamil Rytarowski
2020-09-04 0:29 ` [PATCH v2 07/10] Add a common utility function to read and write siginfo_t in inferior Kamil Rytarowski
2020-09-04 0:29 ` [PATCH v2 08/10] Avoid double free in startup_inferior Kamil Rytarowski
2020-09-07 19:19 ` Simon Marchi
2020-09-08 0:54 ` Kamil Rytarowski
2020-09-08 2:21 ` Simon Marchi
2020-09-04 0:29 ` [PATCH v2 09/10] Switch local native code to gdb/nat shared functions Kamil Rytarowski
2020-09-07 19:24 ` Simon Marchi
2020-09-08 0:04 ` Kamil Rytarowski
2020-09-04 0:29 ` [PATCH v2 10/10] Add minimal and functional NetBSD/amd64 gdbserver Kamil Rytarowski
2020-09-07 19:58 ` Simon Marchi
2020-09-08 0:03 ` Kamil Rytarowski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87a6wlopxd.fsf@tromey.com \
--to=tom@tromey.com \
--cc=gdb-patches@sourceware.org \
--cc=kamil@netbsd.org \
--cc=pedro@palves.net \
--cc=simark@simark.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).