From owner-sc22wg14+sc22wg14-domo2=www.open-std.org@open-std.org Wed Aug 7 23:18:59 2024 Return-Path: X-Original-To: sc22wg14-domo2 Delivered-To: sc22wg14-domo2@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id 3F9FC356FB5; Wed, 7 Aug 2024 23:18:59 +0200 (CEST) Delivered-To: sc22wg14@open-std.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by www.open-std.org (Postfix) with ESMTP id B6B98356AC7 for ; Wed, 7 Aug 2024 23:18:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1723065535; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=v4oYVTemyetjTV9ONkGM3w83n7Nc6WF4vLBtsACipYg=; b=JpmMmDIhd44BEznkrcK/xZmwuOEpuqgyPryxlIJxF9fs3M6OplfkwvD8m+dWEXaNQ+4fjU jTEIfYpT1vYtHBu7xgLwfMDNXOdDYY2gkBHM54SVkhnQrHSqN5ukwDh1C6KruRhl/49C8I dq9OlcrSsNa8T64gDMgUkQ9tutYgMhY= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-494-7nam_1rWPvOxC8hbqk5ZXw-1; Wed, 07 Aug 2024 17:18:53 -0400 X-MC-Unique: 7nam_1rWPvOxC8hbqk5ZXw-1 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-4280a434147so1649495e9.3 for ; Wed, 07 Aug 2024 14:18:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723065532; x=1723670332; h=mime-version:message-id:subject:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=v4oYVTemyetjTV9ONkGM3w83n7Nc6WF4vLBtsACipYg=; b=TT+2qIQ3Ha3bBLvgENgzmPwvkEoGQr9vlvxiLVnyGe+kRqWpwksyF952bGxzL6oOUQ 04R0cqPuWOWClHcCJ9UXBd4n4b/JYFLTqoWc03/0lTNUMeSWQ9MRW3ZwNKFudcEGHjTb xJWm+wDaHb7vUKuMYN2Ogl7rZjwxrFMOBlvqazSmviEIxFcxBnKV9x+KI7AmGoaUYl5J kC+xZnMWgGjx8mcHRMV+dvUxE39utqzUBI1RbKpLROPsdAyRP1veJXjYp7G8xpN1J2LQ vVJpNlDdEIdHe/Gy2X4myzjRG5jPmWVDGG7MnaZ8pozHaKiRsiH2/AX6DnidKbAiZTED 4NNQ== X-Gm-Message-State: AOJu0YyQRcA5HRb5v3xghNmOWqxCeZU7DWwngyGIXNxL2d1XJ1sKyXnn pftS+0uApgR/WxE3lEGlb3CjSTcswjMNWpnWHDFnudU26z5Ha89YqkoCVYTIEE2Rlg/dSvy6cf5 a0BKhEAnuhB8Btwrr62/Cp4W5EuTOyHst9n/ROH8l39Q5d7p7vE/FP+N13BXnbqQA5magebrsaX 4rpZPLhSvity/LAVQ07/TOTAojeleUOGLetjGl X-Received: by 2002:a05:600c:4ed4:b0:428:9ba:39f with SMTP id 5b1f17b1804b1-4290aeee159mr112635e9.11.1723065532270; Wed, 07 Aug 2024 14:18:52 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGtaAnnglED92m/fcD0QS7voRIhnNVVkCG3ON2ItJy7vAXV02QDAzUu1+IfIEwsxRdnTDX8MQ== X-Received: by 2002:a05:600c:4ed4:b0:428:9ba:39f with SMTP id 5b1f17b1804b1-4290aeee159mr112525e9.11.1723065531412; Wed, 07 Aug 2024 14:18:51 -0700 (PDT) Received: from digraph.polyomino.org.uk (digraph.polyomino.org.uk. [2001:8b0:bf73:93f7::51bb:e332]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-429057e8fe9sm29172455e9.1.2024.08.07.14.18.50 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Aug 2024 14:18:51 -0700 (PDT) Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.95) (envelope-from ) id 1sbo2x-00CkvL-Sf for sc22wg14@open-std.org; Wed, 07 Aug 2024 21:18:15 +0000 Date: Wed, 7 Aug 2024 21:18:15 +0000 (UTC) From: Joseph Myers To: sc22wg14@open-std.org Subject: Issues with fopen wording after N3247 Message-ID: <96dd462-5ed8-18d8-3685-7c2449292e30@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Sender: owner-sc22wg14@open-std.org Precedence: bulk Here are some issues with the wording for fopen, beyond the integration issues where I've put straightforward editorial fixes in https://gitlab.gwdg.de/iso-c/draft/-/merge_requests/455 (these ones are issues with the original paper, varying in how straightforward and editorial a fix might be). 1. The wording for '+' needs updating to reflect that it might not be the second or third character any more with relaxed ordering; it could be any character after the first. This could probably be fixed editorially by saying "a" in place of "the second or third". 2. The footnote "If the string begins with one of the listed mode sequences, the implementation can choose to ignore the remaining characters, or it can use them to select different kinds of a file (some of which can potentially not conform to the properties in 7.23.2)." only really made sense as is when there was a full list of possible mode sequences; now there's a mode character followed by other characters in any order, it needs to be rephrased so it no longer talks about "one of the listed mode sequences". Also, we should consider carefully where this footnote should go; is the current paragraph (which starts talking about the first character in the argument, leaving other characters for later) really the best place still? 3. Previously there was explicit undefined behavior for any string not in the given list. Now, there's only explicit undefined behavior if the *first character* isn't in the list; the normative wording says nothing about what happens if any subsequent character is not one for which semantics are defined. Maybe it's implicitly undefined where it says "can contain any of the following characters in any order", if some other character is present, but being explicit is generally better. (This is an example of "undefined behavior as an extension point", where implementations might give other meanings to strings with other characters; cf. the footnote discussed above. A request to make it implementation-defined in C23 CD1 comment GB-210 was rejected (no consensus 4/4/5) with "David Banham asked to bring this suggestion up for C2Y", i.e. a paper making it implementation-defined might be appropriate to consider.) 4. It has been suggested to me that the wording about 'p' is inadequate, because "cannot be accessed by other means" would seem to exclude all the suggested implementation strategies - O_TMPFILE or a suid helper doesn't prevent access via /proc/self/fd/, for example, or by direct privileged access to the underlying device. It may be that this is a case where the normative wording can only be understood to refer to mechanisms within the scope of the standard, however, and as with memset_explicit not all the intent about what is or is not an appropriate implementation strategy can be expressed within the concepts usable in normative wording in terms of the abstract machine. I don't think any of the first three issues affect the wording for fopen_s (N3275) because the fopen_s wording references that for fopen for the relevant issues with interpretation of modes. As for the fourth issue, I tend to think that it would be best for the fopen_s specification to say as little as possible about the semantics of 'x' and 'p', deferring instead to the fopen specification as far as possible. -- Joseph S. Myers josmyers@redhat.com