Hi,
On Fri, May 26, 2023 at 17:09:44 +0100, Ian Abbott wrote:
> As per the C standard, calling ungetc() with the character parameter
> equal to EOF causes it to fail, returning EOF.
>
> Signed-off-by: Ian Abbott <abbotti@xxxxxxxxx>
> ---
> v2: Correct English grammar usage for "otherwise".
> v3: Move detail of EOF special case to the end of the paragraph to give
> it less prominence, as suggested by Alex.
> ---
> man3/fgetc.3 | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/man3/fgetc.3 b/man3/fgetc.3
> index 75dcaeaf6..a15d73b15 100644
> --- a/man3/fgetc.3
> +++ b/man3/fgetc.3
> @@ -62,7 +62,7 @@ A terminating null byte (\[aq]\e0\[aq])
> is stored after the last character in the buffer.
> .PP
> .BR ungetc ()
> -pushes
> +normally pushes
> .I c
> back to
> .IR stream ,
IMO, saying "ungetc() normally pushes c back to stream" is a bit
redundant. After all, pretty much every function "normally does [thing]"
unless an error/exception case is hit.
It also breaks the flow of the previous text where you have, for
example:
fgetc() reads the next character from stream and returns it as an
unsigned char cast to an int, or EOF on end of file or error.
> @@ -71,6 +71,13 @@ cast to
> where it is available for subsequent read operations.
> Pushed-back characters
> will be returned in reverse order; only one pushback is guaranteed.
> +If the value of
> +.I c
> +equals that of the macro
> +.BR EOF ,
> +nothing is pushed back to
> +.I stream
> +and an error is returned.
Similarly, I think you can drop the "that of the macro EOF" and just say
"equals EOF".
- Oskari
> .PP
> Calls to the functions described here can be mixed with each other and with
> calls to other input functions from the
> --
> 2.39.2
>
Attachment:
signature.asc
Description: PGP signature
