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 D105C3834F32 for ; Wed, 22 Jun 2022 10:41:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D105C3834F32 Received: from mail-ej1-f71.google.com (mail-ej1-f71.google.com [209.85.218.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-97-WUdLIOhwMKaD-Uz_NMr11w-1; Wed, 22 Jun 2022 06:41:27 -0400 X-MC-Unique: WUdLIOhwMKaD-Uz_NMr11w-1 Received: by mail-ej1-f71.google.com with SMTP id z7-20020a170906434700b007108b59c212so6185205ejm.5 for ; Wed, 22 Jun 2022 03:41:27 -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=4J/Y4KXC1XIj3UzjxiwsKnz35yzOZchZMyXf1qacXLM=; b=YDSVhFjUuZUkhvSP6J2cYUJ/gkiVBh4nqDb/C82pIW7BXcM/BEBi4C0NEikWf5rwTz zWQ/TeFyYV+ECOiMm9e5rHDSE6KgAU6nrNNT8/kvHDi/G9Rvk/rOVd4Z6of0NDqzLA1E iY5SkZqUQDE6lWml1be+jLaDeLEZw7/k2PK/oSYi+Vzq1bVY9pZl5ALQUz4FF8kFTAWO mVEopd/uk7T/ftAM8SfaSOllTK1KMPhaqCPtLo75yimZSbnfUMg6kiFDdOk1oeXC4VLr g2oNeC4aBlHN/nO9+52yZf4BjIwDBJI01nkCdDZQqX2JkAz2lVrkyHomhJO0Spg8ebGB 5oTw== X-Gm-Message-State: AJIora8ro3w90+UpJ0rvUyY9MDMrp+eRuKuCQzNRhq0sFsoUo1eXr4gh gfbJOBjSA7KKXNWhAPoO6fOYHMinysLBwJDuHY4Zg12dWjIPnDG79CjaAMEHflAkbePQAQtL115 XqEwz3UzNgti8+xEdsFo+usZQv1u4E8Q= X-Received: by 2002:a17:907:9491:b0:722:f2a1:efb6 with SMTP id dm17-20020a170907949100b00722f2a1efb6mr1947064ejc.284.1655894486136; Wed, 22 Jun 2022 03:41:26 -0700 (PDT) X-Google-Smtp-Source: AGRyM1sdaQHJU01+ztAGGjUqq3VT4nEZn5JMKXIpQ6PWpBNwfF8Auiz2WtaFS7ffWHiq3+Q9zbHHuEcMq6ukU6ESOOs= X-Received: by 2002:a17:907:9491:b0:722:f2a1:efb6 with SMTP id dm17-20020a170907949100b00722f2a1efb6mr1947054ejc.284.1655894485978; Wed, 22 Jun 2022 03:41:25 -0700 (PDT) MIME-Version: 1.0 References: <4fe20709-e617-7644-175c-bd49b52dc6c2@embedded-brains.de> In-Reply-To: From: Jonathan Wakely Date: Wed, 22 Jun 2022 11:41:14 +0100 Message-ID: Subject: Re: [PATCH] libstdc++: testsuite: fs rename to self may fail To: Alexandre Oliva Cc: Sebastian Huber , "libstdc++" , gcc Patches , RTEMS X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-7.2 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=ham 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 10:41:30 -0000 On Wed, 22 Jun 2022 at 08:02, Alexandre Oliva via Libstdc++ wrote: > > Hello, Sebastian, > > On Jun 22, 2022, Sebastian Huber wrote: > > > On 22/06/2022 08:24, Alexandre Oliva via Libstdc++ wrote: > >> rtems6's rename() implementation errors with EEXIST when the rename-to > >> filename exists, even when renaming a file to itself or when renaming > >> a nonexisting file. Adjust expectations. > >> > >> Regstrapped on x86_64-linux-gnu, also tested with a cross to > >> aarch64-rtems6. Ok to install? > >> > >> PS:https://devel.rtems.org/ticket/2169 doesn't seem to suggest plans to > >> change behavior so as to comply with POSIX. > > > I would not adjust the test case to cope with systems which are not in > > line with POSIX. > > My understanding is that the libstdc++ testsuite is not meant to test > for POSIX conformance, but for conformance with the C++ language > standards. > > C++ inherits rename from C, and C says the behavior is implementation > defined if the new name already exists. std::filesystem::rename is explicitly specified in terms of POSIX rename, not C rename. POSIX says: "If the old argument and the new argument resolve to either the same existing directory entry or different directory entries for the same existing file, rename() shall return successfully and perform no other action." and "If the link named by the new argument exists, it shall be removed and old renamed to new." So I agree with Sebastian, the tests are correct. Instead, the implementation of std::filesystem::rename should have a special-case for rtems (and maybe other targets) that implements the POSIX rename semantics if calling ::rename isn't good enough. > > RTEMS is thus comformant with the requirements from C (and thus C++), > and it is therefore reasonable for libstdc++'s testsuite to accept > RTEMS' behavior as such. > > > That said, because libstdc++ tests are all-or-nothing, perhaps it would > make sense to have a separate test for strict POSIX conformance in > rename, XFAILed on RTEMS targets. How about that? > > -- > Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ > Free Software Activist GNU Toolchain Engineer > Disinformation flourishes because many people care deeply about injustice > but very few check the facts. Ask me about >