From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) by sourceware.org (Postfix) with ESMTPS id 5B6523861885 for ; Thu, 28 Sep 2023 15:52:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5B6523861885 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wr1-x429.google.com with SMTP id ffacd0b85a97d-32008e339adso12155426f8f.2 for ; Thu, 28 Sep 2023 08:52:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695916365; x=1696521165; darn=sourceware.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=ObjZoFQFI9rvJrGn8x7VkeGv4J6lEdFKCyWcMh18T+E=; b=hVlHVZAIo0KdgHWQtLfIdo9uoaqtXydYkZ3buika9DEdnO1craPI8UI7E/xb0UFoFc 56LPmtID0pBn1Mbo45enCu1jqEY6TLToCf9XMc9fNYHqPmPOCeCvu0I09zmtwMkDWqag JdDupgpMssgP1hun81F7oH6Sla8shYPXNtsSi/Xud86RhmhNrZyPCuLqbfIgN9AFP6F1 iArs12ArsKXBRVb72Rdjy1KwvaqzR/94tHaz6zRiI/YmJF94zk9lbN85vkpmV1Gqmy+c xJVzfUuFippGEukJquPEe+M3uLPt3qNHLgAJ/f2i+M3lZPc++JHeFQNwAWJeuwFLIR4z Ld0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695916365; x=1696521165; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ObjZoFQFI9rvJrGn8x7VkeGv4J6lEdFKCyWcMh18T+E=; b=qLOIy/7lPXkATW3nBzIF68XerF3QK7wNf/C0OFU4xgeuKD20VyUhV1kpYw249ot/pz oKUbi0liTWo/GAUT90uUSMnnndpszasea0u1eb40lmIBY3+pbX8Uii8DawWDAHB9T0kk eGAUsrM5f5vtHJ4oGLRKwzzNWQS3Q/mEbqffZ5TiTVHJbjNVJlWPc23QsiCD3oMTRkDh gJFQy2gX9SHqjmXiXjngaOkKRdzDUitaPZaNohGeOPpLn8RDCs3sMeq3iIn84NWawURj 9lDxDV+/VVDqLu+hj2XvYf0nGsMxoLxlDHihfeSHJIRyXhmimcbIpavdJfN2HYjaS6mg 9oXQ== X-Gm-Message-State: AOJu0YyX88x5ANlI74r+/4EGgp3/PntG/3MhcMyrYPAAIECrxjA1JjPc R8GjbJjEP/17YnJKBO3vhy30s/ozOyTKSg== X-Google-Smtp-Source: AGHT+IHcpuj1hGkAurpnqYAQKLuqOEXWTY7CHfcaYwfCzRkWWL0PomdHkyCuKEQt+gKvI44FXwmqqw== X-Received: by 2002:a5d:6406:0:b0:31a:d2f9:7372 with SMTP id z6-20020a5d6406000000b0031ad2f97372mr1546102wru.29.1695916364621; Thu, 28 Sep 2023 08:52:44 -0700 (PDT) Received: from [10.96.0.25] ([146.70.48.3]) by smtp.gmail.com with ESMTPSA id f17-20020a1c6a11000000b00402f745c5ffsm20375226wmc.8.2023.09.28.08.52.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 28 Sep 2023 08:52:44 -0700 (PDT) Message-ID: <1203ae0f-3444-d702-d4ec-d6639db254ab@gmail.com> Date: Thu, 28 Sep 2023 16:52:43 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: [PATCH] nss: Get rid of alloca usage in makedb's write_output. Content-Language: en-US To: Andreas Schwab , Joe Simmons-Talbott Cc: libc-alpha@sourceware.org References: <20230926135528.3517253-1-josimmon@redhat.com> <20230928131432.GB4098455@oak> From: Gabriel Ravier In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 9/28/23 14:32, Andreas Schwab wrote: > On Sep 28 2023, Joe Simmons-Talbott wrote: > >> On Thu, Sep 28, 2023 at 01:16:00PM +0200, Andreas Schwab wrote: >>> On Sep 26 2023, Joe Simmons-Talbott wrote: >>> >>>> @@ -802,6 +812,7 @@ write_output (int fd) >>>> assert (iov_nelts <= INT_MAX); >>>> if (writev (fd, iov, iov_nelts) != keydataoffset) >>>> { >>>> + scratch_buffer_free (&sbuf); >>>> error (0, errno, gettext ("failed to write new database file")); >>>> return EXIT_FAILURE; >>> Does scratch_buffer_free guarantee that errno is not changed? >> scratch_buffer_free doesn't do anything other than call free when the >> buffer has been heap-allocated. IIUC free preserves errno since 2.33 in >> the default free. So I guess if there is a non-default free that >> doesn't preserve errno then there is no explicit guarantee. Should I >> adjust scratch_buffer_free to explicitly preserve errno (in a separate >> patch) or just preserve errno around this one call to >> scratch_buffer_free? > You could just move the call down. > Hmmm, this solves the issue for this patch but it seems like something that would merit further discussion in my opinion - personally I think the answer should just be to assume a compliant `free` is present, but others might have good arguments as to why this shouldn't be the case.