From patchwork Wed Sep 25 21:28:45 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Joseph Myers X-Patchwork-Id: 97975 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 1DD0B3858420 for ; Wed, 25 Sep 2024 21:29:59 +0000 (GMT) X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTP id 9EC813858D35 for ; Wed, 25 Sep 2024 21:29:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9EC813858D35 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 9EC813858D35 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1727299776; cv=none; b=kR0geN1tIhZmGKEkibbZsWUWAkilluwmPKBDDDixDiiPRJcGHwEcRJJ30ht0YcFoDueIUe6LwdP1M5gZZIjjwe/usD+xL2UEeeEOs0diw4a6+y9Tzg1lKCZxhxtv4U0jjeXWPicA9lddlvW3EC4aKtDnmMmOZar2TqJl51yzJ1A= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1727299776; c=relaxed/simple; bh=8mDkLnpu8g9Gg57SHSdoDh3ZxtXQK9zI2c62n2bOplI=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=n8p/f6T5P9tl9wTBHmRY38ZQuy6ulONHrTdUFoJ+EsYt+SMnNYbxpT42aj8a0u28hPV0eW/jwbx40cMBY2LdvO7376Ec8dfnOPXr3vvDNK3zCHnfcboR2Xyr/m8dPjAG4yMsBGMFnqCVgbWzinQEZXIW4TkAbq88w9ZT8DEauIk= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1727299774; 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=E54qhKL2ZfOR/YMHoJvHpOoAqZJEx6xt7Uktx/YWbYQ=; b=VzeqNrSDm+YXfQc7qDSlsE/+N/OZ72R161pHRVIknpBU2YAoyjYZwsyNJzV1z5GXlrspsR gD2X8NArvp/kOVffi6DOmFIq+6xPExPORauL/FoDcwQEtuQXhzxWYkf8r2NQvap2ab6oMc J1WLVYHTkuwCjBodvjk8iRY+p2clhXE= 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-619-npXSf6IBMw2-fbI-BfszIQ-1; Wed, 25 Sep 2024 17:29:32 -0400 X-MC-Unique: npXSf6IBMw2-fbI-BfszIQ-1 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-42caca7215dso1209325e9.2 for ; Wed, 25 Sep 2024 14:29:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727299771; x=1727904571; h=mime-version:message-id:subject:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=E54qhKL2ZfOR/YMHoJvHpOoAqZJEx6xt7Uktx/YWbYQ=; b=H0uGQwyC+KpBPd9y/DnUiXjQay0QeFZHyyJaTJtCXVlXJ1dEVmmOppUU22/Bk2Gy5Q AV0Dr6qIGfOBgC8KTbCFAb/aETS0QmaMJqzUuH6+hO0+btIsGeopQEOlXZS7/sVSV7hj zssN0mk26JRxdmjaLpF1q+ZCCHlWikjH3rbIxTWxqSZ6tOGGvPt92xp1T7OqQCB5U4eK neW98GimVJb4ca/RBFBcQoSDC1XE/Rr4YZAWYKkBsH8rUBowjukjRPGMRuTMU1XHjjMO gdtl9vVsJM45OZ7Wzc6o+QSWK3sikXCLm6wouAZYjIag0GdserHQ6U2DOuITy6RgJdEN 5a0g== X-Gm-Message-State: AOJu0Yz0YXrUE94nb+ikD2BFzjZpDruTSG2ewAP8DaVOwzcjMdvZr3B/ uuepV4u14bl/tpI+Xaalg6a8VT8oiV9ygzCGx/xzwCP40HKxsIzNMDUj4wsigs55fBGUT+3xV8H mPBXZp+ffQ50hpx6zuJ285VezT8Lqu+23AERKisYSpr3plFHgLBXoclfPmv54qdIM4J42zZjdHW e9jGUUa3LC3JxZChBq7y4GTbPhdJ2M1D9Go8mQA92SuA== X-Received: by 2002:a05:600c:510e:b0:42b:ac80:52ea with SMTP id 5b1f17b1804b1-42e96103397mr23362385e9.6.1727299771432; Wed, 25 Sep 2024 14:29:31 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEgt1qj3EkacMXqrl2FHVdoNs4A+2h+M8fYR9HuE/5zLqLQuSeZzEf7g0qB9oFkRzQyhD6uBg== X-Received: by 2002:a05:600c:510e:b0:42b:ac80:52ea with SMTP id 5b1f17b1804b1-42e96103397mr23362325e9.6.1727299770987; Wed, 25 Sep 2024 14:29:30 -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-42e969e194bsm28927315e9.1.2024.09.25.14.29.30 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 25 Sep 2024 14:29:30 -0700 (PDT) Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.97) (envelope-from ) id 1stZYz-00000001WDQ-26jH for libc-alpha@sourceware.org; Wed, 25 Sep 2024 21:28:45 +0000 Date: Wed, 25 Sep 2024 21:28:45 +0000 (UTC) From: Joseph Myers To: libc-alpha@sourceware.org Subject: Document further requirement on mixing streams / file descriptors Message-ID: <46008e45-db75-c168-70fe-3c5b5009a9b5@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-Spam-Status: No, score=-9.1 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, 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 X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: libc-alpha-bounces~patchwork=sourceware.org@sourceware.org The gilbc manual has some documentation in llio.texi of requirements for moving between I/O on FILE * streams and file descriptors on the same open file description. The documentation of what must be done on a FILE * stream to move from it to either a file descriptor or another FILE * for the same open file description seems to match POSIX. However, there is an additional requirement in POSIX on the *second* of the two handles being moved between, which is not mentioned in the glibc manual: "If any previous active handle has been used by a function that explicitly changed the file offset, except as required above for the first handle, the application shall perform an lseek() or fseek() (as appropriate to the type of handle) to an appropriate location.". Document this requirement on seeking in the glibc manual. Note that I'm not sure what the "except as required above for the first handle" is meant to be about, so I haven't documented anything for it. As far as I can tell, nothing specified for moving from the first handle actually list calling a seek function as one of the steps to be done. (Current POSIX doesn't seem to have any relevant rationale for this section. The rationale in the 1996 edition says "In requiring the seek to an appropriate location for the new handle, the application is required to know what it is doing if it is passing streams with seeks involved. If the required seek is not done, the results are undefined (and in fact the program probably will not work on many common implementations)." - which also doesn't help in understanding the purpose of "except as required above for the first handle".) Tested with "make info" and "make pdf". diff --git a/manual/llio.texi b/manual/llio.texi index a035c3e20f..3ea5c352ee 100644 --- a/manual/llio.texi +++ b/manual/llio.texi @@ -1097,6 +1097,21 @@ streams persist in other processes, their file positions become undefined as a result. To prevent this, you must clean up the streams before destroying them. +In addition to cleaning up a stream before doing I/O using another +linked channel, additional precautions are needed to ensure a +well-defined file position indicator in some cases. If both the +following conditions hold, you must set the file position indicator on +the new channel (either a stream or a descriptor) using a function +such as @code{fseek} or @code{lseek}. + +@itemize @bullet +@item At least one of the old and new linked channels is a stream. + +@item The file position indicator was previously set (using the old +linked channel or a previous channel linked to it) with a function +such as @code{fseek} or @code{lseek}. +@end itemize + @node Independent Channels @subsection Independent Channels @cindex independent channels