From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 7751F3834F01 for ; Wed, 22 Jun 2022 09:16:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7751F3834F01 Received: from mail-ed1-f69.google.com (mail-ed1-f69.google.com [209.85.208.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-421-AWUkP585PVuE7Kt7Mq8gQg-1; Wed, 22 Jun 2022 05:16:52 -0400 X-MC-Unique: AWUkP585PVuE7Kt7Mq8gQg-1 Received: by mail-ed1-f69.google.com with SMTP id q18-20020a056402519200b004358ce90d97so5179940edd.4 for ; Wed, 22 Jun 2022 02:16:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IopLIqDILVHARclg8bp802U0vRe1shhxHmaofHtObyI=; b=r0agunmUPFT8S9YBvyzJj62OLEosx7ggSs0xU9qg9YwlvVeA61T0ZkqhBvtgClfAym /XXGGFeVOhUxtiTJAHwyVdFqestVwRcpd3Gj+SdVXPtcK7efS372aIKU9RmvPiTkuQK6 kx5U7zPK5/6/ZBVSx6DgmnshJPj2ncYsiP84pz8PZkVoToYFiVZlKQL+LplDrn45lcLv zKMuyPu49euEXJriH/iw9IS1vMY3YD4eU1woamp5z4L8SPYQUCcA3jLIIUgrnNN6Cj2H aKtOAMg9YeHBUbYBrkH1Dd+As/29LFOHkaA55HOWm812uLp/7pDj6RhotGVN0lYiLJTX 2CjA== X-Gm-Message-State: AJIora84OaPQuMBfMe0rFXD5EMtyRf7ENbJAFSbh2nJStSJ66zfHIHws j111YWcfKqilPNEUeR3Mt26LqoSElzbGi/PsUFCA6ZwT76dMUj8oC2UtJ3svKK+cKwqIOt71N11 ekAsJSJuPBE44bFmMFGatBb0mx7NBzYo= X-Received: by 2002:a05:6402:3808:b0:435:5a6c:9dd9 with SMTP id es8-20020a056402380800b004355a6c9dd9mr3022232edb.368.1655889411085; Wed, 22 Jun 2022 02:16:51 -0700 (PDT) X-Google-Smtp-Source: AGRyM1vqJMzmiF7GLgeokZ7K5u59IYz0xnvsFPGSRTCvf6jOWqlVhzOIdacAL6tEBDze5IVDo9OSBzJLayQ2CUgBTIg= X-Received: by 2002:a05:6402:3808:b0:435:5a6c:9dd9 with SMTP id es8-20020a056402380800b004355a6c9dd9mr3022209edb.368.1655889410806; Wed, 22 Jun 2022 02:16:50 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jonathan Wakely Date: Wed, 22 Jun 2022 10:16:40 +0100 Message-ID: Subject: Re: [PATCH] libstdc++: testsuite: avoid predictable mkstemp To: Alexandre Oliva Cc: gcc Patches , "libstdc++" X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: libstdc++@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libstdc++ mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2022 09:16:55 -0000 On Wed, 22 Jun 2022 at 07:05, Alexandre Oliva via Libstdc++ wrote: > > > This patch was originally meant to reduce the likelihood that > nonexistent_path() returns the same pathname for from and to. > > It was prompted by a target system with a non-random implementation of > mkstemp, that returns a predictable sequence of filenames and selects > the first one that isn't already taken. > > That turned out not to be enough: nonexistent_path adds a suffix to > the filename chosen by mkstemp and removes the file it created, so > mkstemp may very well insist on the same basename, and the case that > doesn't use mkstemp doesn't even check whether the file already > exists. > > Anyway, by the time I realized this wasn't enough, I'd already > implemented some of the changes, and I figured I might as well > contribute them, even though they don't really solve any problem, and > even if they did, they'd be just a partial solution. > > Regstrapped on x86_64-linux-gnu, also tested with a cross to > aarch64-rtems6. Ok to install? OK