Re: C90 fpeek

"Kaz Kylheku" <643-408-1753@kylheku.com> wrote in message
news:20250124111822.327@kylheku.com...

When a standardization effort was launched, two groups were formed:
one of the language and one for the OS.
>
The language one took the closer-to-the-language things like
printf and malloc and fopen.
>
The OS group took the system level things like open, read, write.
>
The fpeek function you're looking for can be writen in POSIX
as a combination of fileno (to obtain the integer file descriptor
from a FILE * stream) and a polling function like poll or select,
executed with a zero timeout.

That's my point though - I'm after a solution from the language
side. I'm not interested in just one OS (POSIX).

Someone mentioned threads in C23 - but I assume that is a
massive overhead - if possible at all in an environment like
MSDOS.

fpeek() I can envisage happening in MSDOS. An appropriate
C library could query the UART to see if there is a character
pending. Or perhaps a fairly slightly modified MSDOS could
do that. Or a serial driver could independently read from the
UART and construct a buffer.

Note that having an fpeek would allow me to cope with
buffer overruns on an error-free link that lacks flow control.
However, it alone won't cope with line noise that garbles
a ZNAK response, as both ends would be blocked on
reading in that case.

But - and this is unusual - I'm happy to live with that. I'm not
after a perfect solution, I'm after a simple solution that in this
case assumes an error-free connection (ie I'm using an MNP4
modem or it's really TCP/IP or whatever).

However, I am still mulling over whether I could handle a
garbled ZNAK, by having the sender repeatedly send XON,
going back to do an fpeek, until either the ZNAK is completed,
or the receiver realizes that the ZNAK was likely lost, and
sends another.

Another unusual thing - I'm willing to change the zmodem protocol.
The work that I am doing is all with the benefit of hindsight, and
I'm (sort of) not trying to run existing applications. Even if I am, I
for example forked gcc 3.2.3 and removed all the POSIX stuff
to create a C90 application (ie a lot of work).

If I can't have an fpeek as a C90 extension - so be it - I just say
that you can't have buffer overruns - it must be error free, and
speed limited so that the receiver isn't overwhelmed. Otherwise
both systems need to be rebooted or whatever in order to
continue working.

Another unusual thing - this is to create a simple "starter system".
It's not meant to be the last word in file transfers or anything else.
But I do expect to have the tools required to build "the world's
greatest OS", so I provide a C compiler, and I do want to be
able to collaborate electronically instead of having to send a
USB stick or floppy disk in the post. If that means the stars
need to be aligned for a zmodem transfer to go through - so be it -
the alternative isn't a modern 2025 system - the alternative is
carrier pigeons (literally in fact - I do envisage a Fidonet or UUCP
system running without the internet, and pigeons being exchanged
at schools - possibly schools in Bhutan - see the reference in
Sneakernet wikipedia) - but I'm not there yet).

Another option I have is that on the first ZNAK - or any line noise
in fact - I switch to requiring ACKs.

Note that I can't really properly verbalize what I want to do. I see
the C90 standard and I like it. I'm tempted to say "for its simplicity",
but without much of a reference point, I don't know that that is
correct. E.g. I think it is odd that sin() etc were added, as they are
not required for base functionality (writing a C compiler). So I might
be looking at a stripped down C90 - while still adding extensions.
I don't want timing in my applications. I don't want multithreading.
It just "seems wrong" (rightly or wrongly). The C90 people
certainly didn't add such things - perhaps they had the same vague
"feelings", or perhaps they explained why in the ANSI Rationale
which I haven't yet read.

But an fpeek which is allowed to fail, is something that doesn't
make me uncomfortable right at the moment - rightly or wrongly.

Back to mulling zmodem extensions - if the ZNAK may not
have gotten through, I don't want to send another because
timing issues (especially communicating with Mars) may mean
I am NAKing a good packet. I may want to switch to ACKing
the last good packet. Or perhaps non-blocking ACKing.

BFN. Paul.