Document further requirement on mixing streams / file descriptors
Florian Weimer
fweimer@redhat.com
Thu Sep 26 08:28:03 GMT 2024
* Joseph Myers:
> The gilbc manual has some documentation in llio.texi of requirements
Typo: g[lib]c
> 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
For context, this updates the Linked Channels subsection, which is about
channels with the same underlying file description.
I do not think this rules accurate. The standard streams are linked
channels, typically with descriptors for the file description in the
parent process. They are streams. A freshly started program does not
know if another program seeked any of the descriptors before. Does this
mean programs need to add fseek calls for the standard streams? What if
those streams are not seekable?
I think we have a step missing in the cleaning process: the new channel
may indeed need seeking. The current manual suggests that cleaning is
only needed on the old channel, but I don't think this is accurate, for
both linked and independent channels. For example, an input stream may
have old file contents buffered.
Thanks,
Florian
More information about the Libc-alpha
mailing list