Sujet : C90 fpeek
De : mutazilah (at) *nospam* gmail.com (Paul Edwards)
Groupes : comp.lang.cDate : 24. Jan 2025, 04:08:44
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vmv082$1u6pm$1@dont-email.me>
User-Agent : Microsoft Outlook Express 6.00.2800.1106
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).
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?
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.
Thanks. Paul.
P.S. zpg.zip (z/PDOS-generic) from
https://pdos.org is now
self-hosting - gccmvs (gcc 3.2.3) can rebuild itself, byte-exact.
It runs under Hercules/380 (herc32.zip or herc64.zip) and
microemacs is provided too. This is for an IBM mainframe and
it uses EBCDIC (including a FAT32 file system in EBCDIC).
I'm starting preparations to dial a BBS (using Virtualbox to
link COM1 to an IP address) to talk to the world.