Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Kaz Kylheku <643-408-1753@kylheku.com>
Newsgroups: comp.lang.c
Subject: Re: C90 fpeek
Date: Fri, 24 Jan 2025 19:48:59 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 48
Message-ID: <20250124114602.417@kylheku.com>
References: <vmv082$1u6pm$1@dont-email.me>
 <87plkc6bgm.fsf@nosuchdomain.example.com> <a7NkP.76379$ZEZf.241@fx40.iad>
Injection-Date: Fri, 24 Jan 2025 20:49:00 +0100 (CET)
Injection-Info: dont-email.me; posting-host="7f33a37540ba8b226dd6885cb0d9398b";
	logging-data="2502239"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+k+WVd5jc9C7YhDE0rsTPzJSIJaM0/9D0="
User-Agent: slrn/pre1.0.4-9 (Linux)
Cancel-Lock: sha1:gAt/6q8vVkDe8ySUlm0UxPX4M+Q=
Bytes: 2711

On 2025-01-24, Scott Lurndal <scott@slp53.sl.home> wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>"Paul Edwards" <mutazilah@gmail.com> writes:
>>[...]
>>> With the benefit of hindsight, is there any reason why fpeek
>>> couldn't have been added to C90, with implementations
>>> being allowed with just a macro that returns some sort of
>>> "unsupported"?
>>>
>>> If fpeek (or similar) makes sense, can someone suggest an
>>> appropriate interface?
>>[...]
>>
>>It would help to know what "fpeek" is supposed to do.  There no such
>>function in any edition of the C standard or in any implementation
>>that I'm aware of.
>
> And indeed, giving the default buffering in stdio, the concept of
> peek with respect to a serial port doesn't make a whole lot of
> sense.

It absolutely does; have you never done a poll() or select() on a tty
file descriptor?

The argument could be made to have a poll-like function in C,
that works with FILE * streams.

I could use such a thing in POSIX programs. Working with stdio streams
while doing multiplexing of real-time I/O though them onto a single
thread is a bit ugly.

> Note that 'getc()'/'ungetc()' is effectively a peek
> operation.

Nope, because getc will block when there is no data.

Unless you non-portably arranged otherwise. E.g. on POSIX
we can get the fileno(stream), and use fcntl to set up O_NONBLOCK.
Then get(stream) returns EOF, with errno set to EWOULDBLOCK
and we whave to clearerr(stream), then poll the fd, and so it goes.

Been there done that. Went back there, done that again,
and then several more times, like a raging masochist.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca