From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-74.mimecast.com (us-smtp-delivery-74.mimecast.com [216.205.24.74]) by sourceware.org (Postfix) with ESMTP id 5FE16385E006 for ; Fri, 27 Mar 2020 18:20:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 5FE16385E006 Received: from mail-ed1-f70.google.com (mail-ed1-f70.google.com [209.85.208.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-99-RC8aQyB0MtKoyzXGn5-Ojw-1; Fri, 27 Mar 2020 14:20:50 -0400 X-MC-Unique: RC8aQyB0MtKoyzXGn5-Ojw-1 Received: by mail-ed1-f70.google.com with SMTP id cm25so1105132edb.14 for ; Fri, 27 Mar 2020 11:20:50 -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=DMzzzZJHjbt2JInJNtajJbUSEqdPI25Byx/QVPZr2oU=; b=q7gFIBBuyBrbwctrJZmO9G32QR8/xxYlCnpYcZFbvUkGLw2M5bTigqGSOSLx48CfXr XCS1GlLSGCxUVxLu7Vv9OOTLvty1Ck/lx2fb1wMBg6LKjuQ5ks3U7BsQASUlyR8mjhgt XRerqWjZHmXHa+ieMdIFR+FNz+JNEat75iguROqDJl7cUkMUtFkwW8+oaLJZioTR2WS3 dMogf0LgyVQwQybFQf30fbg9StQNrlW2j23FloKnzJVZEPZThLyl6Lls/gUgNld+gJoh USCyTEKOvchL5N01pDv4j3CrdVHlOvjr+Z2pNBuaC824q1HVElCfaOY+VGgGIbIYNWKC SobQ== X-Gm-Message-State: ANhLgQ22dNpDmkvzSX70+uOsgb0pNxkVTJzJG1cvPgx1Ke7qYyKrUbYQ 4i3uvx8Lwv3cNeaVHxHVSIflQpwObH3922qcH+ggPMoGSMNlJxbdELfP8z7N2nK5JsSWP9582bV IYGC0LkdkFexx94VnEeFGbA== X-Received: by 2002:a17:906:1c55:: with SMTP id l21mr249836ejg.333.1585333249135; Fri, 27 Mar 2020 11:20:49 -0700 (PDT) X-Google-Smtp-Source: ADFU+vsofvYUfSZmuSxj9C+TBCHnP/JobE32ui80onruOP4gkm7lQHacIVu0gwNtQcW7fxGU5nfHXw== X-Received: by 2002:a17:906:1c55:: with SMTP id l21mr249816ejg.333.1585333248889; Fri, 27 Mar 2020 11:20:48 -0700 (PDT) Received: from ?IPv6:2001:8a0:f909:7b00:56ee:75ff:fe8d:232b? ([2001:8a0:f909:7b00:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id a25sm991754edt.45.2020.03.27.11.20.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 27 Mar 2020 11:20:47 -0700 (PDT) Subject: Re: [PATCH v2 2/5] Don't reset errno/bfd_error on 'throw_perror_with_name' To: Sergio Durigan Junior , GDB Patches References: <20200226200542.746617-1-sergiodj@redhat.com> <20200317154719.2078283-1-sergiodj@redhat.com> <20200317154719.2078283-3-sergiodj@redhat.com> Cc: Tom Tromey From: Pedro Alves Message-ID: Date: Fri, 27 Mar 2020 18:20:46 +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: <20200317154719.2078283-3-sergiodj@redhat.com> Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-8.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org 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: , X-List-Received-Date: Fri, 27 Mar 2020 18:20:54 -0000 On 3/17/20 3:47 PM, Sergio Durigan Junior via Gdb-patches wrote: > the commit that "introduced" it is: > > commit c906108c21474dfb4ed285bcc0ac6fe02cd400cc > Author: Stan Shebs > Date: Fri Apr 16 01:35:26 1999 +0000 > > Initial creation of sourceware repository > > so yeah... Given the previous discussions, I'd appreciate this comment was updated/clarified. > > If we go to the POSIX specification for 'perror', it doesn't really > say anything about whether errno should be preserved or not. It does, > however, say that 'perror's messages should be the same as those > returned by 'strerror', and 'strerror' is not supposed to alter errno > if the call is successful. > > Maybe when our wrapper was written it was OK to modify errno, I don't > know. But I'd like to propose that we stick to POSIX in this case. > This really has nothing to do with POSIX, because this isn't a normal wrapper. Control is not returning, we're throwing. As I mentioned before, we shouldn't be relying on errno being preserved across throw/catch. For _that_ reason, I'm still OK with this patch, (even though I disagree with the given rationale). Thanks, Pedro Alves