Re: C90 fpeek

On 2025-01-24, Paul Edwards <mutazilah@gmail.com> wrote:

I am able to open COM1: with C90 fopen and do a zmodem
file transfer on the stream.
>
So long as it is an error-free environment, I can switch between
reading and writing so long as I do the C90-required fseek. I
simply fseek by 0 from SEEK_CUR.
>
However, if there is line noise, it is unpredictable when there
will be a NAK coming down the line.
>
So what I would like to do is fseek of 0, then fpeek(stream),
and if it says there is data available, I read it. On streams where
peeking is not available, it does an appropriate return, and I
rely on it being an error-free environment (as now, ie I'm no
worse off).

C stdio lets you read one character and then put it back
into the stream with ungetc.

There is no non-blocking I/O.

There is no way to detect whether an input stream has
buffered data that may be read immediately without waiting.

Beyond the buffer, there is no way to detect whether data has arrived
from the outside environment into the host system, such that a
subsequent operation that needs to ask the host for data in order to
replenish the stream buffer will not block.

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"?

For C90, part of the answer would be that the committe
was in codifying-existing-practice mode, and not so much
in invent-new-cruft mode.

There was no fpeek out in the wild to standardize.

ANSI C saw itself as standardizing the portable parts of
the C language as it came from Unix. Operating system
stuff was left to the POSIX group.

POSIX provides a way to access the underlying file descriptor
of a stream: via int fileno(FILE *).

There are ways of detecting unread data, but they are device
specific. It's a bit of a mess.

If fpeek (or similar) makes sense, can someone suggest an
appropriate interface?
>
Before sending a NAK I probably want to do an fdiscard
of the input stream too. But again with no guarantees that
the data will be discarded, and my protocol needs to allow
for that.

What does discard mean? Without any knowledge of how much data is
buffered, in what places,  and precise control over what is discarded,
it's just a hand-wavy operation.

Discarding an unknown amount of buffered input is counterproductive in
the face of a streaming or sliding window type protocol!

You're likely discarding a good packet (or portion thereof) that is
coming on the heels of the bad one you are NAKing.

The receiver shoold read everything and make the best out of every byte.

What you need for a proper Zmodem implementation isn't "fpeek" but a
good measure of concurrency or some facsimile thereof. The sender has to
keep transmitting data nonstop, while receiving and responding to NAKs.

In the POSIX world, you could do this in a single thread with the select
or poll functions. These functions take multiple open file descriptors
as inputs and return an indication whether the desired conditions are
true, like data being avaialble in input descriptors, or output
descriptors having space for more data. These functions can block while
none of the conditions are satisifed.

The problem can be solved with threads also (which C now has as of C11).

You may be able to open two FILE * descriptors on the serial port,
one for reading and one for writing. Have a dedicated thread which
reads the responses, looking for NAKs, and a decidated thread
for sending. The two can coordinate their actitivies. The sender
can have a queue of what to send next, and NAK processing can
push a retransmit item that queue.

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