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?
"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.
"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.
"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.
On 1/24/25 00:13, Keith Thompson wrote:
"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.
A google search uncovered a stackoverflow question for which the
answer was:
int fpeek(FILE *stream)
{
int c;
c = fgetc(stream);
ungetc(c, stream);
return c;
}
I don't see any reason why such a function is needed in the standard
library. However, if it were added, since fgetc() and ungetc() are
mandatory for hosted implementations, I also see no reason to allow
for it to be unsupported.
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.
"Keith Thompson" <Keith.S.Thompson+u@gmail.com> wrote in message news:87plkc6bgm.fsf@nosuchdomain.example.com...
"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.
fpeek would tell you whether there are any characters available
to be read, on a bidirectional data stream, opened with r+b or
whatever.
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.
Note that 'getc()'/'ungetc()' is effectively a peek
operation.
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.
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?
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.
I don't recall ever using stdio streams myself for any real world
problem - for terminal input I generally use libreadline or libedit;
for serial port input/output, open + tcsetattr + fcntl (usually with O_NOCTTY) + read or write.
Kaz Kylheku <643-408-1753@kylheku.com> writes:
It absolutely does; have you never done a poll() or select() on a tty
file descriptor?
Hundreds of times over the last 35 years. Never on a buffered stdio
stream for which poll is basically useless.
And always with O_NONBLOCK set
on the file descriptor (from open, not fopen+fileno()), usually with
the underlying tty or pty set to so-called 'raw' mode.
On 1/24/2025 11:48 AM, Kaz Kylheku wrote:
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.
Why not use AIO?
On 2025-01-24, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
On 1/24/2025 11:48 AM, Kaz Kylheku wrote:
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.
Why not use AIO?
In conjunction with stdio buffering? It doesn't seem possible; you have
to go through alternative functions like aio_read, which stdio doesn't interface with.
A stdio implementation that uses aio_read and friends under the hood
might be interesting.
Why not use AIO?
... not useful for OP's purouses without ability to
set file to O_NONBLOCK. Which, I would think, is outside of C standard.
You could argue that if I'm willing to add ANSI X3.64,
why not also add C23 and POSIX and ...
I don't have a good answer to that, other than I'm trying to keep
movement away from C90 to a minimum.
On Sat, 25 Jan 2025 10:58:32 +1100, Paul Edwards wrote:
You could argue that if I'm willing to add ANSI X3.64,
why not also add C23 and POSIX and ...
I don't have a good answer to that, other than I'm trying to keep
movement away from C90 to a minimum.
Let me suggest a more reasonable baseline for code that is to be minimally relevant to this century: C99 + POSIX.
Sysop: | DaiTengu |
---|---|
Location: | Appleton, WI |
Users: | 1,007 |
Nodes: | 10 (0 / 10) |
Uptime: | 196:48:05 |
Calls: | 13,143 |
Files: | 186,574 |
D/L today: |
511 files (113M bytes) |
Messages: | 3,310,136 |