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 CA0293834F2C for ; Wed, 22 Jun 2022 10:41:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CA0293834F2C Received: from mail-ej1-f70.google.com (mail-ej1-f70.google.com [209.85.218.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-97-7mvZv15qNL-dT6FNh3AKig-1; Wed, 22 Jun 2022 06:41:27 -0400 X-MC-Unique: 7mvZv15qNL-dT6FNh3AKig-1 Received: by mail-ej1-f70.google.com with SMTP id k7-20020a1709062a4700b006fe92440164so6167511eje.23 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=ZdXqkxLtJtj49lrJuZUBxuBSvuOW/J7EHvIj+y04T/MQhotd9v2FMV71mZJKWgjw6M tQVWQKWQD7qf5HUqgbMobgrRuCm/EyZ84E0xedN9igsOHiYinDoMNm1Vu/Tx1dP6Z06e eIVGqOCubZ2oCIqUIF4CwCpRSVQ6/lOEf/ZL7wS2Xn4wtvJKXYV+ogY1O6bQTjVplnpx vu/TbKyYGePzufMBUsghelgB59WoNTTLUelJ62ZHri+l7h/CgIQw/STLITEiKSOs4Dp8 zwV2siA47CxGiErps8OpEF+35Rnn8H5oS48RWnYIajRuXxbSi+9pG0raIbtvW9le1YeB ER8A== X-Gm-Message-State: AJIora/iyW7WCS8UT0bhoHfvjBOxIlBHgdPPPYvA8IK7kMDK0KQKzC89 06JdAqGJOYxR/cqKwENRQTC5z24h1Y4KhTGYUXzHZ4u9mjv7W0x27UlwEsCKlFnMitAWrd5Mffm ov7qRCES8otQxoC4bjoqeMkz87hNZ8y7xXA== X-Received: by 2002:a17:907:9491:b0:722:f2a1:efb6 with SMTP id dm17-20020a170907949100b00722f2a1efb6mr1947066ejc.284.1655894486138; 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.3 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: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches 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 >