From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id oD3sCIrWll/eHgAAWB0awg (envelope-from ) for ; Mon, 26 Oct 2020 10:00:42 -0400 Received: by simark.ca (Postfix, from userid 112) id 203F11F08D; Mon, 26 Oct 2020 10:00:42 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id C852F1E552 for ; Mon, 26 Oct 2020 10:00:41 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 88C2C3899073; Mon, 26 Oct 2020 14:00:41 +0000 (GMT) Received: from mail-wr1-f65.google.com (mail-wr1-f65.google.com [209.85.221.65]) by sourceware.org (Postfix) with ESMTPS id 11368389703A for ; Mon, 26 Oct 2020 14:00:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 11368389703A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=alves.ped@gmail.com Received: by mail-wr1-f65.google.com with SMTP id b8so12742468wrn.0 for ; Mon, 26 Oct 2020 07:00:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=jYjhkeIwBoLOuWOFJHS4U1//fEq+mOO9ebdx3j0kKSQ=; b=k0p8PnUg6JB3Hg6CsYpamSjgCnFrY2DKLaQaqKATjKmm+1qz0f0CxhpBCX5Hh6ZCoC FlUe6aOXOzB1Ni7TmK7oHXyYL0SyDZs3lsc5wpQTALYk0RJwWQjx54zHaEmJydWaI6dD Pj75sAx0iUaxSvzYXbNN6XV3jSw7Vjo9yKb7AEo1arUD6Eu5eKKM7/5nOzQpr6ORo3dE y5JxargtYJ4HIgm3fMVJKBXR4Vq7BGJVap+b5EfmJo0t8OGOLVx5jE8sT1mfC8VK8XHO AJeCSDSXgxd7wf5DxTJph10hYYeCaFrp2OK1eT8qhazT3zOBKIaaywVq2ngAhEnxFIF3 mSmg== X-Gm-Message-State: AOAM532SCpNpQ/sqbEoxJDY7BestU51wQtvbp+yhJ4T3OZIvu022DwYp Qxp3C9coxCnClFn/28clg8ygutgjhuCg/w== X-Google-Smtp-Source: ABdhPJxZqkEoKsY3JF9Na9OndEQYKBSX0issmirazDC30EboZda7Y0BI7DBVbeF/MQHFW1vBjELn9g== X-Received: by 2002:a5d:4fcc:: with SMTP id h12mr18911463wrw.132.1603720836629; Mon, 26 Oct 2020 07:00:36 -0700 (PDT) Received: from ?IPv6:2001:8a0:f91e:6d00:f223:ef68:24e0:af8f? ([2001:8a0:f91e:6d00:f223:ef68:24e0:af8f]) by smtp.gmail.com with ESMTPSA id v19sm19454104wmj.31.2020.10.26.07.00.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Oct 2020 07:00:35 -0700 (PDT) Subject: Re: [PATCH v2] gdb::handle_eintr, remove need to specify return type To: Tom Tromey References: <20200904002905.13616-1-n54@gmx.com> <20200904002905.13616-2-n54@gmx.com> <75070000-03a2-eeed-4f72-e29f199291af@palves.net> <223cf7ec-36b5-fe52-7d0f-e19c335be534@palves.net> <87a6wlopxd.fsf@tromey.com> From: Pedro Alves Message-ID: Date: Mon, 26 Oct 2020 14:00:34 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <87a6wlopxd.fsf@tromey.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Simon Marchi , Kamil Rytarowski , gdb-patches@sourceware.org Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" On 10/16/20 9:51 PM, Tom Tromey wrote: >>>>>> "Pedro" == Pedro Alves 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 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? I don't think so. But I don't think it really matters -- I look at it as ErrorValType being the type of the value used to compare with the wrapped function's return type. Like, with: ssize_t read(int fildes, void *buf, size_t nbyte); we normally write: ssize_t res = read (fildes, buf, nbyte); if (res == -1) instead of ssize_t res = read (fildes, buf, nbyte); if (res == (ssize_t) -1) So ErrorValType is the type of the "-1" expression. It just has to be convertible to the return type. If we get rid of the ErrorValType template parameter, then we could do instead: template using return_type = decltype (std::declval () (std::declval ()...)); template inline auto handle_eintr (return_type errval, const Fun &f, const Args &... args) -> decltype (f (args...)) { decltype (f (args...)) ret; do { errno = 0; ret = f (args...); } while (ret == errval && errno == EINTR); return ret; } That works for me too, though it looks a little more complicated, I think. Let me know which version you prefer. > 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. That thought initially crossed my mind too, but IMHO it's not worth it. You have to write the helper template class, so it doesn't look like a net win over writing a plain wrapper like: int my_waitpid (int pid, int *status, int flags) { return gdb::handle_eintr (-1, ::waitpid, pid, status, flags); } and using my_waitpid throughout. I.e., this way we also only write the -1 once.